Reading view
The Latest Push to Extend Key US Spy Powers Is Still a Mess
NASA Employees Duped in Chinese Phishing Scheme Targeting U.S. Defense Software
Bridging the AI Agent Authority Gap: Continuous Observability as the Decision Engine
26 FakeWallet Apps Found on Apple App Store Targeting Crypto Seed Phrases
What Really Happened In There? A Tamper-Evident Audit Trail for AI Agents
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.
[link] [comments]
Tropic Trooper Uses Trojanized SumatraPDF and GitHub to Deploy AdaptixC2
LMDeploy CVE-2026-33626 Flaw Exploited Within 13 Hours of Disclosure
Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain ...
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
[link] [comments]
Newly Deciphered Sabotage Malware May Have Targeted Iranβs Nuclear Programβand Predates Stuxnet
GopherWhisper: A burrow full of malware
UNC6692 Impersonates IT Help Desk via Microsoft Teams to Deploy SNOW Malware
OAuth 2.0 BCP Β§4.14 reuse detection in practice β race vs theft disambiguation
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/)
[link] [comments]
Bitwarden CLI Compromised in Ongoing Checkmarx Supply Chain Campaign
ThreatsDay Bulletin: $290M DeFi Hack, macOS LotL Abuse, ProxySmart SIM Farms +25 New Stories