I wrote a custom jellyfin addon to get back access to ssh

Full disclosure: I work on community at Always Further, the team behind this. Not the author. Posting because Luke's approach to tackling this challenge is unique and of an interest to the netsec community.

The core idea: if an AI agent is compromised, any log the agent itself writes becomes part of the attack surface. The post walks through how they split auditing into a supervisor process the sandboxed child can't reach, then uses the same Merkle tree + hash-chain construction RFC 6962 (Certificate Transparency) uses to make edits, truncation, and reordering all detectable.

There's a concrete threat-model table near the end that lists what each attack looks like and what structurally stops it. Worth skipping to if you don't want the crypto primer.

Bitwarden CLI npm package got compromised today, looks like part of the ongoing Checkmarx supply chain attack

If you’re using @bitwarden/cli version 2026.4.0, you might want to check your setup

From what researchers found:

- malicious file added (bw1.js)

- steals creds from GitHub, npm, AWS, Azure, GCP, SSH, env vars

- can read GitHub Actions runner memory

- exfiltrates data and even tries to spread via npm + workflows

- adds persistence through bash/zsh profiles

Some weird indicators:

- calls to audit.checkmarx.cx

- temp file like /tmp/tmp.987654321.lock

- random public repos with dune-style names (atreides, fremen etc.)

- commits with “LongLiveTheResistanceAgainstMachines”

Important part, this is only the npm CLI package right now, not the extensions or main apps

If you used it recently:

probably safest to rotate your tokens and check your CI logs and repos

Source is Socket research (posted a few hours ago)

Curious if anyone here actually got hit or noticed anything weird

Standard advice for refresh tokens: rotate on every use, store hashed, set a short expiry. Done, right?

Not quite.

Rotation alone does nothing against token theft. If malware or XSS lifts a refresh token from a legit client, the attacker and the client race to rotate it next. Whoever loses the race gets a "token revoked" error — and the winner keeps the session.

From the server’s point of view, it just sees two valid requests seconds apart. No alarm, no signal, nothing.

The missing piece is what OAuth 2.0 Security BCP §4.14 calls refresh token reuse detection: if a token that was already rotated is presented again, treat it as evidence of compromise and invalidate the entire session.

The core idea

Every token belongs to a family (FamilyId), shared across all rotations of a single login.

If a rotated token shows up again (outside a small grace window), you revoke the entire family:

• the attacker is locked out
• the legit user is forced to re-authenticate
• the session is no longer silently compromised

​

if (stored.ReplacedByTokenHash is not null && stored.RevokedAtUtc.HasValue) { var withinGrace = stored.RevokedAtUtc.Value.AddSeconds(graceSeconds) > DateTime.UtcNow; if (withinGrace) return Fail("token_recently_rotated"); // benign race (SPA tabs, retries) await RevokeFamilyAsync(stored.FamilyId, ip, reason: "reuse_detected"); return Fail("token_reuse_detected"); } 

Client-side it’s just one extra branch:

if (error.code === "token_reuse_detected") { // "You've been signed out for security reasons. Please log in again." router.push("/login?reason=compromised"); } 

You can also hook into it for observability (alerts, SIEM, etc.):

services.AddSingleton<IAuthEventSink, SlackAlertSink>(); 

The tricky parts

• Race vs theft look identical. Two requests with the same token arrive. One is legit, one might not be. Only timing differs. Grace window too small → false positives on flaky networks. Too large → real attack window. ~30 seconds worked well in practice.
• Revoking the whole chain. On reuse you must invalidate all still-active tokens from that session. A simple FamilyId + index makes this a single bulk update.
• Concurrency is common. Multi-tab SPAs, retries, mobile reconnects — without a grace window, I was logging myself out constantly during tests.

I ended up adding this to a small self-hosted auth library I’ve been working on (https://www.reddit.com/r/dotnet/comments/1shpady/selfhosted\_auth\_lib\_for\_net/)

Some more information from the author of PackageKit on https://www.openwall.com/lists/oss-security/2026/04/22/6 too.

Expect to see reliable (public) exploits pretty soon.

CVE-2026-32604 and CVE-2026-32613 are both 10.0 severity vulnerabilities in Spinnaker, which allow attackers to execute arbitrary code and access production cloud environments and source control.

They provide an easy path from a compromised workstation to more sensitive areas.

Our blog post contains a comprehensive technical breakdown and working POCs.

Perforce is source control software used in games, entertainment, and a few engineering sectors. It's particularly useful when large binary assets need to be stored alongside source code. It handles binary assets much better than Git, IMO. However, its one weakness is its terrible security defaults. You will die a bit inside when you see the out-of-the-box behaviour: "Don't have an account? Let me make one for you!" and "Oh, you didn't know by default there is a hidden, read-only 'remote' user that allows read access to everything? Oops!"

I scanned 6,122 public Perforce servers last year. 72% were exposing source code, 21% had passwordless accounts, and 4% had unprotected superusers (which allow RCE). The vendor patched the largest issue, but a significant portion are still vulnerable.

Full write-up and methodology: https://morganrobertson.net/p4wned/

Tools repo, including Nuclei templates to scan your infra: https://github.com/flyingllama87/p4wned

Hardening is a pain, but here it is summed up: p4 configure set security=4 # disables the built-in 'remote' user + strong auth p4 configure set dm.user.noautocreate=2 # kills auto-signup p4 configure set dm.user.setinitialpasswd=0 # users cannot self-set first password p4 configure set dm.user.resetpassword=1 # force password reset flow p4 configure set dm.info.hide=1 # hide server license, internal IP, root path p4 configure set run.users.authorize=1 # user listing requires auth p4 configure set dm.user.hideinvalid=1 # no hints on bad login p4 configure set dm.keys.hide=2 # hide stored key/value pairs from non-admins p4 configure set server.rolechecks=1 # prevent P4AUTH misuse

Happy to answer any questions on the research!

[ Removed by Reddit on account of violating the content policy. ]

We analysed almost 100 UK charity websites and found that ~1 in 6 are running vulnerable JavaScript dependencies.

What stood out more though:

- Some vulnerabilities were 10+ years old, including high and critical ratings

- Same jQuery CVE (2015-9251) appearing across multiple organisations

We’ve now seen similar patterns in the HE/FE and also hospitality sectors as well.

Are we right in thinking that this feels like a visibility problem alongside budget issues more than anything else?

How are you tracking dependencies effectively in your organisations?

Full write-up if useful: https://cybaa.io/blog/2026-04-20/uk-health-charity-website-security-2026