Contents
Anthropic began emailing Claude users on August 30 with a warning most SaaS companies dread having to send: infostealer malware sitting on some customers’ own machines had stolen their active login sessions, and attackers were using those sessions to log in as them, no password or second factor required. The company is now signing out affected sessions, stripping saved payment methods, and refunding charges it can identify as unauthorized.
This is not a Claude vulnerability in the way that phrase usually gets used. Anthropic’s infrastructure was not breached, and the malware was not delivered through Claude. But it matters anyway, because it is a clean, public case study in a gap that most people’s mental model of account security still misses: multi-factor authentication protects the login, not the session that comes after it. Any SaaS account with a browser tab open long enough is exposed to the same attack, and AI accounts, with metered usage and saved payment methods attached, are an unusually attractive target to drain.
How the theft actually works
MFA guards the door, not the room. Once you complete login and MFA, your browser stores a session cookie that says “already authenticated” for every request after that. Infostealer malware, running locally on an already-compromised machine, does not try to guess your password or intercept a one-time code. It just reads that cookie off disk and hands it to the attacker, who replays it and is treated as you, mid-session, with MFA never re-prompted. The theft happens after the security check that was supposed to stop it.
This is commodity malware, not a targeted hack. Anthropic named the families involved: Vidar, LummaC2, StealC, RedLine, and Acreed on Windows, plus Atomic Stealer on a small number of Mac devices. These are off-the-shelf tools sold cheaply on criminal forums, built to vacuum up browser passwords, cookies, and crypto wallets from any infected machine, with no interest in which specific sites the victim happened to be logged into. Claude accounts got swept up because people were logged in when their machines were compromised by something else entirely, a pirated app, a fake installer, a malicious browser extension.
The response is necessarily reactive, and incomplete on its own. Anthropic can revoke a stolen session and remove a payment method, but it explicitly warned users that this only closes the one hole it can see: if the malware is still running on the victim’s machine, the next login just hands the attacker a fresh cookie. The actual fix has to happen off-platform, on the endpoint, which is true of every service the same victim is logged into, not just Claude.
Would your defenses have caught it
About the demo
This models the general shape of session-hijacking defenses, not Anthropic’s specific internal controls. Toggle the mitigations to see which combination would have stopped a replayed cookie.Pick a replay scenario and toggle the defenses.
Set the replay scenario to “same device and network” and switch everything off. Nothing catches it, because a cookie replayed from the exact environment it was stolen in is indistinguishable from the real user, by design. That single case is why endpoint hygiene, not platform-side detection, has to be the actual fix: no amount of anomaly detection helps when the attacker’s traffic looks identical to yours.
What this actually means for you
The uncomfortable takeaway is that MFA fatigue is quietly being replaced by session fatigue, and most people, and a fair number of engineering teams, still design their security posture around the login event instead of the session that follows it. If you run infrastructure with long-lived sessions and no step-up re-auth on sensitive actions like changing a payment method or rotating an API key, you have the same exposure Anthropic just described, regardless of what product you’re building.
My practical next step: shorten session token lifetimes on anything that touches billing or credentials, add step-up re-auth specifically for payment and security-setting changes rather than relying on session validity alone, and treat “run an up-to-date antivirus and don’t install browser extensions from outside the store” as advice worth repeating to your own users, not just something IT tells you once. If you’re building agentic tools that hold live authenticated sessions on someone’s behalf, the way Claude Code or Claude in Chrome do, this is also a reminder that the session your agent is operating with deserves the same scrutiny as the session a human is operating with. It’s the same cookie either way.