AI Coding Assistants Face Critical Security Risks: RCE and Supply Chain Attacks

Three AI coding agents, three critical RCEs — and the same trust-boundary bug in all of them

Security researchers just dropped a coordinated disclosure of critical AI coding assistant vulnerabilities affecting Claude Code, Gemini CLI, and OpenAI Codex — the three most widely deployed agentic coding workflows shipping in production today. An attacker-controlled issue or zero-privilege input can breach the trust boundaries of the agent "harness" — the permissions, tools, sandbox, filesystem, and automation wrapped around the model — and walk away with code execution, stolen secrets, or a fully compromised developer workflow.

This isn't a vendor-bashing post. The disclosure is the field working as intended: external researchers found a real class of bug, the vendors coordinated on fixes, and builders get to ship safer code as a result. But the pattern matters more than any single instance. The same architectural choice — a permissive harness around a capable model — appears across all three systems, and it's a pattern that's going to keep repeating until the harness itself is treated as part of the attack surface.

Here's what's actually disclosed, what it enables, and how to keep shipping with AI coding assistants without handing your repo to an attacker.

What's actually disclosed

The vulnerability class targets the agent harness — the wrapper that gives the model shell access, file edits, network calls, and tool invocations. The harness is what turns a language model into a coding agent. The disclosed class of bug lets an attacker with zero privileges — a GitHub issue, a PR description, a comment on a ticket, an @-mention in a chat channel the agent is wired into — escalate to full code execution on the developer's machine by walking through whatever the harness is configured to trust.

Per the disclosure, all three vendors — Anthropic (Claude Code), Google (Gemini CLI), and OpenAI (Codex) — were affected by the same class of issue. The researcher framing calls the harness the new perimeter: it's the boundary between "things the model can read" and "things the model can do", and the disclosed bugs live in that boundary's validation logic.

Why it matters: every team that uses these tools to triage issues, auto-review PRs, or chain agents into CI is sitting inside that harness. When the harness trusts the wrong input, every downstream action — pushing code, reading secrets, calling internal APIs — happens inside the attacker's kill chain.

How the exploit walks the harness

The mechanism is straightforward enough to reason about, and that's exactly why it's dangerous.

1. The attacker drops a malicious payload somewhere the agent will read it — an issue body, a PR description, a file in the repo, a chat thread the agent monitors.
2. The agent's prompt-construction layer pulls the payload into its context. Up to this point, the model has just "read" the payload — no execution yet.
3. The harness then acts on what the model returns: tool calls, file writes, shell commands. The bug is that the harness doesn't reliably distinguish between "instructions from the operator" and "data scraped from an untrusted source."
4. The model's output — now shaped by attacker-controlled input — triggers a privileged tool call. That tool call runs in the developer's environment, with the developer's credentials, against the developer's git remote.

The blast radius is whatever the harness can reach. On a developer laptop, that's usually: the entire home directory, the SSH keys, the GitHub PAT in the keychain, the cloud CLI session, and any CI tokens in ~/.config/. In a CI workflow, it's the runner's mounted secrets and the production deploy credentials.

What an attacker can take in a single pass:

This is not a theoretical chain. The disclosure calls out code execution, secret theft, and workflow compromise as the three documented outcomes. Treat them as the realistic floor, not the ceiling.

Implications for developers and organisations

If your team uses any of these three agents — and most professional JavaScript and Python teams use at least one in some form today — the blast radius extends past the individual developer. A compromised agent that pushes to a protected branch is a supply-chain attack: every downstream consumer of that repo now pulls attacker-controlled code. A compromised agent with cloud credentials can pivot into your production account, mint new IAM keys, and persist access long after the original machine is wiped.

The cascading pattern is the part that makes this class of bug scary. One malicious issue on a public repo → one developer's compromised machine → one poisoned merge → thousands of downstream pullers compromised. The same playbook that has hit popular package registries in past supply-chain incidents runs again, but the entry point is now an AI coding assistant with a permissive harness instead of a maintainer's compromised laptop.

This is the trust-boundary bug that keeps reappearing. Vendors will patch the specific instance. The architectural pattern — "give the model everything and trust it to be careful" — is what actually needs to change.

How to mitigate this today

Don't wait for a vendor patch. Most of the load-bearing mitigations are configuration choices you can make right now.

Constrain the harness, not the model. The model is going to do what the input tells it to do; that's the whole point of a model. The real fix lives in the harness configuration:

• Pin tool scopes. Don't let the agent run bash(*) — make it run bash(git:*) or bash(npm test). Whitelist by command, not by category.
• Default-deny filesystem writes outside the repo. /etc/, ~/.ssh/, ~/.aws/, ~/.config/gh/ should be read-only mounts for the harness, full stop.
• Strip secrets from the runtime environment. Mount a scrubbed view into the agent's process; don't hand it your real ~/.aws/credentials. A tempfile with the keys it actually needs, rotated per run, is a much smaller blast radius.
• Block egress to anything not on an allowlist. The model doesn't need to call arbitrary hosts from your build step. If a tool call wants to make a network request, it should be one you've explicitly approved.

# Example: a tight harness config (shape only — pin to your vendor's current schema)
{
  "permissions": {
    "bash":    ["git status", "git diff", "npm test"],
    "edit":    ["src/**", "tests/**"],
    "network": ["github.com", "registry.npmjs.org"]
  },
  "filesystem": {
    "writable":  ["./"],
    "readOnly":  ["/etc", "~/.ssh", "~/.aws", "~/.config/gh"]
  }
}

Treat agent output as untrusted input. Don't pipe agent output back into another agent without sanitising. If Agent A reads an issue and Agent B runs the fix Agent A suggested, you've just built a two-stage prompt-injection chain — and the attacker only needs to win the first one.

Run agents in disposable sandboxes. A container or VM you snapshot before and revert after every agent run. If the harness gets popped, the attacker gets the sandbox, not your laptop.

Audit what the agent actually did. Every modern harness ships an action log. Mine it. A git diff post-run that doesn't match the issue you opened it on is a red flag, not a feature.

The part that doesn't change when the agent does

Here's the durable lesson that survives the next CVE cycle: the agent is a moving target, the surface you're protecting isn't.

The agent harness will get patched, the next vendor will ship a tighter default, and researchers will find the next class of bug in three months. That's the churn layer. The thing that doesn't churn is what the agent is allowed to touch — your repo structure, your component contracts, your config files, your deployment targets. If that surface is small, well-typed, and explicit, every agent that runs against it inherits the constraint for free.

This is the same reason teams that standardised on a single component kit ship safer agentic code than teams that freestyle. A dropdown is a dropdown whether Claude Code, Gemini CLI, or Codex is rendering it. A config file is a config file regardless of which model is reading it. A typed component contract is harder to subvert than a pile of generated CSS — the agent either matches the contract or the build fails, and there's no soft middle where the attacker's payload can land.

The architectural pattern that holds up under adversarial agents is the same one that holds up under adversarial humans: make the safe path the easy path, and make the unsafe path require an explicit override. Defaults do more security work than policies.

The future of agent harness security

Three trends worth watching:

1. Harnesses will ship deny-by-default permissions. The vendors know. Expect the next major release of all three to ship narrower default tool scopes and require explicit opt-in for filesystem writes and network egress.
2. Runtime attestation will become table stakes. Cryptographically signing what the harness actually did — every file write, every tool call — so a compromised agent leaves a verifiable trail instead of a git log you have to reverse-engineer.
3. The community will demand "agent SBOMs". A bill of materials listing which tools, scopes, and permissions a given agent workflow uses, reviewable like a dependency tree. Pull a new agent version, see exactly what its harness can touch.

None of that ships the malicious issue out of existence. But it shrinks the blast radius until the next research disclosure is a write-up instead of an incident.

Keep shipping

AI coding assistants are capable tools and they're going to get more capable. The disclosed class of bug is real, it's cross-vendor, and it warrants the configuration hardening above. None of it is a reason to stop using these tools — it's a reason to use them with a tighter harness and a smaller attack surface.

The model changes every quarter. The repo you're shipping to production next Friday doesn't. Build the surface so that the agent — whichever one, this cycle and the next — has the least possible room to misbehave, and the disclosed bugs stop being your Friday-afternoon problem.

Source: Critical flaws in Claude Code, Gemini CLI, and OpenAI Codex enable RCE and supply chain attacks