Claude Code, Gemini CLI and Codex all fell to the same researcher at Black Hat — using nothing but default settings
A single security researcher disclosed critical flaws in Anthropic's Claude Code, Google's Gemini CLI and OpenAI's Codex at Black Hat USA 2026 — all found in the vendors' own public repositories running default configuration, and all exploitable for remote code execution or credential theft via prompt injection.
8 August 2026
Security researcher Elad Meged of Novee disclosed, at Black Hat USA 2026 on 7 August, a matched set of critical vulnerabilities across the three most widely used AI coding agents — Anthropic’s Claude Code, Google’s Gemini CLI and OpenAI’s Codex. What makes this disclosure land differently to the usual steady drip of individual CVEs is the method: Meged tested each vendor’s own public repository, running each tool’s default configuration, and found a working exploit path in all three.
The specifics differ but the shape doesn’t. In Claude Code, a permissive default git push validation rule could be manipulated into executing arbitrary commands on GitHub Actions runners, going on to enable arbitrary file reads and exposure of workflow secrets — including GITHUB_TOKEN and ANTHROPIC_API_KEY. Anthropic shipped several interim patches before the final fix was assigned CVE-2026-54316. In Gemini CLI, two separate assumptions failed at once: a “restricted” shell tool that turned out not to be enforced at runtime, and credential sanitisation that stripped secrets from child processes but left them reachable to a compromised child through Linux’s own process interfaces. Google rated it CVSS 10.0 — the maximum possible score — and pushed a breaking change to its non-interactive trust model in response. In Codex, the problem was structural rather than a single bug: multi-stage automated workflows that share a writable checkout let an early, untrusted-input-processing stage plant a poisoned AGENTS.md file that a later, more trusted Codex run then loads and treats as instructions.
Every one of the three routes back to the same root cause — prompt injection via untrusted input (a GitHub issue, a workflow trigger, a file an earlier stage wrote) crossing a boundary it shouldn’t have had the authority to cross.
So what
This isn’t a story about any one vendor being careless — three separate engineering teams converged on structurally similar mistakes, which says more about the difficulty of the underlying problem than about any single product. For a business running (or about to run) AI coding agents inside CI/CD pipelines, the practical takeaway isn’t “switch tools” — it’s that default configuration on any of these platforms is not a safe assumption for automated, non-interactive execution. Least-privilege scoping on tokens, isolated execution environments for anything touching untrusted input, and treating agent-written or workflow-written files as untrusted until validated are no longer advanced practices; they’re the baseline for anyone letting an AI agent run unattended against a real codebase.
If you’re building AI-assisted development into your engineering process and want that built with this kind of threat model in mind from day one rather than retrofitted after a disclosure, see how we approach AI-assisted development or get in touch to talk it through.