Claude Code has a read-only permission mode: a validator that decides which shell commands are safe enough to run without asking the user first. Anthropic's own security-advisories page says that validator could be fooled into approving a command that actually executed arbitrary code.
What the source says
Tracked as CVE-2025-66032 (GHSA-xq4m-mc3c-vvg3, CWE-77, CVSS v4.0 8.7/High), reported by security researcher RyotaK of GMO Flatt Security Inc. and published directly on Anthropic's own claude-code security-advisories page — a vendor disclosing a flaw in its own product, not a third party's write-up of it.
The bug: the read-only validator was pattern-matching the surface form of a proposed command rather than correctly parsing what the shell would actually do with it. Two specific parsing gaps did the damage — $IFS (the shell's field-separator variable, usable in place of a literal space) and certain short CLI flag forms. A command built around either could be classified read-only and auto-approved, then execute arbitrary code when it actually ran.
Anthropic's advisory states the precondition plainly: "reliably exploiting this requires the ability to add untrusted content into a Claude Code context window." This is a bypass of the read-only gate, not a standalone remote-execution hole — it becomes dangerous once paired with a prompt-injection vector: a malicious file, issue, or tool output the agent reads during a session.
Affected versions: @anthropic-ai/claude-code before 1.0.93. The fix in 1.0.93 didn't just patch the two parsing cases — it replaced the validator's blocklist ("these commands aren't safe") with an allowlist. That's a structural change, and a telling one: a blocklist is exactly the kind of check this class of bypass exploits, because it only has to fail to anticipate one shell construct.
What it doesn't establish
This is a responsibly disclosed research finding. Anthropic's advisory reports no in-the-wild exploitation before the fix shipped. Users on Claude Code's standard auto-update channel received the fix without taking any action. There is no confirmed case of this bypass being combined with a real prompt-injection payload against a real user — the advisory establishes that the gate could be defeated, not that it was.
Why it's still worth logging
Read-only mode is the specific mechanism that lets an agent act without a human in the loop for "safe" operations. A flaw in the validator behind it isn't a bug in some unrelated feature — it's a bug in the trust boundary the feature exists to enforce. And the fix itself is an admission about the failure mode: replacing a blocklist with an allowlist is Anthropic's own acknowledgment that enumerating unsafe shell constructs doesn't scale, which is worth knowing if your own tooling gates agent actions the same way.
Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0121/
Top comments (0)