Anthropic has quietly patched a flaw in Claude Code that let attackers smuggle credentials and source code out of its network sandbox, security researcher Aonan Guan revealed in research published May 20. The fix landed weeks earlier, in version 2.1.90, with no CVE, no advisory, and nothing in the changelog to tell anyone it happened.
How a single null byte broke the wall
The trick is almost insultingly simple. Claude Code's sandbox checks outbound connections against a user-defined allowlist, something like *.google.com. Guan, who leads cloud and AI security at Wyze Labs, found that gluing a null byte into a hostname (attacker-host.com\x00.google.com) turns the two halves of the system against each other.
The JavaScript filter reads the whole string, sees a tidy .google.com ending, and waves it through. Then libc, handling the actual DNS lookup, stops reading at the null byte and dials the attacker's host instead. Same bytes, two interpretations, and the boundary the user thought they had is gone.
On its own that gets you nowhere. Paired with prompt injection, a hidden instruction tucked into a GitHub issue comment or a README that Claude reads, it gets you plenty. Guan's technical writeup spells out the haul: environment variables, AWS and GitHub credentials, the GitHub token Claude authenticated with, cloud metadata, internal APIs. Anything the sandbox could touch could be shipped to any server on the internet.
The sandbox was never actually closed
Here is the part that should worry teams. Guan found that every Claude Code release from the sandbox's debut in October through 2.1.89 was vulnerable to this bug, and the earliest builds were exposed to a second one too. That earlier flaw, a config-parsing mistake that read "block everything" as "allow everything," eventually earned CVE-2025-66479. "There was never a moment when the sandbox actually worked," Guan wrote, which is blunt, but the timeline backs him up.
Anthropic told The Register it found and fixed the latest bug before Guan's report came in, through a public commit anyone can inspect. Fine. The company's spokesperson dated that fix to version 2.1.88 on March 31; Guan's research pins it to 2.1.90 on April 1. They cannot quite agree on which release closed the hole, which does not inspire confidence about how clearly any of it reached users.
No CVE, no email, just upgrade and assume
Guan's real complaint is not the timeline. It is the silence.
"Shipping a sandbox with a hole is worse than not shipping one. The user with no sandbox knows they have no boundary. The user with a broken sandbox thinks they do."
Hard to argue with. A team that ran a wildcard allowlist on a credential-heavy machine for roughly five and a half months got no banner and no security note. They upgrade and assume the sandbox always worked. When Guan showed Claude its own exploit, the model reportedly agreed it was "a real bypass of the network sandbox filter," which is either reassuring or unsettling depending on your mood.
Guan filed his report through HackerOne in April; it was closed as a duplicate of an internal finding. His advice for anyone still on an affected build: check your version with claude --version, upgrade past 2.1.90, and if you ran a wildcard allowlist on a sensitive system, rotate the credentials that machine could reach.
