Three AI Coding Agents, One Trick: What Black Hat Exposed

Anyone can open a public GitHub issue. No login beyond a free account, no special access, no trust required. That low bar turned out to be enough to reach code execution and stolen credentials inside three unrelated companies’ AI coding tools, using the same basic trick each time. The findings, presented at Black Hat USA 2026 in Las Vegas, are not really a story about three separate bugs. They are a story about what happens when a tool built to read code starts reading everything else too, and cannot tell the difference.

What a coding agent actually does once it’s wired into your pipeline

A zero-trust mindset, the assumption that nothing gets automatic trust just because it is already inside the network, is exactly what these tools skip by default. A coding agent is software that reads a prompt, decides what code changes or commands are needed, and then carries them out on its own, often inside a continuous integration pipeline (an automated system that runs code, tests, and scripts every time a repository changes, without a human clicking a button each time). Point one at a public code repository and it can triage bug reports, draft fixes, respond to comments, or run maintenance tasks automatically.

The convenience is real. It is also the exposure. An agent plugged into that kind of automation does not only see the code you wrote. It sees whatever lands in the repository’s public surface: issue text submitted by strangers, comments, configuration files, anything that flows through the pipeline it is watching. If you have connected, or are thinking about connecting, a coding assistant to that kind of setup, the question worth checking is not whether the tool is smart enough. It is whether it can reliably tell content to summarize apart from instructions to obey.

The same confusion, found three separate times

At Black Hat, researchers from the security firm Novee Security presented a talk titled “Trusted Enough to Run: Breaking AI Agents in Official Workflows,” walking through three coding agents from three different vendors that all failed the same test. In each case, an outside attacker with zero repository permissions planted hidden instructions inside content the agent would routinely process, most often a public GitHub issue. When the automated pipeline picked that content up, the agent did not treat it as a bug report to read. It treated it as a command to follow, a pattern security researchers call prompt injection.

That single confusion, once triggered, opened the door to genuinely serious outcomes: running arbitrary commands on the machine executing the pipeline, reading files and secrets that should have stayed private, or planting instructions that would quietly persist and get followed again later. None of it required the attacker to guess a password or exploit a network flaw first. The entry point was public, unauthenticated text that the software had been trusted to process automatically.

Elad Meged, a founding engineer at Novee and one of the researchers behind the talk, framed the pattern plainly in the team’s writeup: these tools were built to be useful inside automation, and that same design made them reachable by anyone who could write text into the right field. Novee’s own account of the findings is the most direct source on the specifics, and it is worth reading in full if you run any of these products in CI.

Claude Code: a chain that ended in a data leak through a public counter

Anthropic’s command-line coding tool, Claude Code (not to be confused with the Claude chat app), was affected by a vulnerability tracked as CVE-2026-54316, fixed in version 2.1.163. A CVE, short for Common Vulnerabilities and Exposures, is simply the public catalog entry that MITRE assigns to a disclosed security flaw, so researchers, vendors, and defenders can all refer to the same issue by the same number.

Claude Code — Anthropic’s agentic coding tool that runs in the terminal and in CI pipelines.

Here it is worth separating what is officially confirmed from what the researcher additionally describes. The CVE’s own text names one thing: a data-exfiltration channel, out-of-band, via a domain the tool had pre-approved without restricting which paths on it were safe to fetch. An attacker could leak a stolen API key one character at a time by abusing Hugging Face’s public model-download counter, a number visible to anyone, as an unlikely but functional side channel for smuggling data out. The researcher who found it, Novee Security, describes a longer chain leading up to that step, including a command-injection route and a way to read arbitrary files, but that broader narrative has not been independently confirmed by Anthropic; only the Hugging Face exfiltration channel is what the official CVE record names. The flaw affected Claude Code versions 0.2.54 through 2.1.162 and was fixed in version 2.1.163. Anthropic had already shipped several incremental patches, removing overly broad shell permission rules and restricting the Hugging Face domain, before the CVE was formally assigned.

Gemini CLI: a sandbox that could be bypassed before it started

Google’s Gemini CLI (again, distinct from the Gemini chat app or the underlying model) carried the most severe rating of the three: CVE-2026-12537, with a CVSS score of 10.0, the maximum possible on that scale. CVSS, the Common Vulnerability Scoring System, is an industry-standard formula for rating how serious a flaw is, from 0 to 10, based on how easy it is to exploit and how much damage it can do. The full advisory is documented under GitHub’s security advisory ID GHSA-wpqr-6v78-jr5g.

The root cause was an operating-system command injection flaw in the launcher responsible for starting the tool’s sandbox, the isolated container meant to contain whatever the agent does. A crafted .gemini/.env configuration file could trigger code execution on the host machine before the sandbox even started, defeating the isolation entirely. A second, related flaw let a supposedly contained child process read the parent process’s secrets, including GitHub tokens and Gemini API keys, through a Linux system file (/proc/$PPID/environ) that exposes a running process’s environment variables. Google fixed both issues in Gemini CLI version 0.39.1, alongside a companion tool update, and the fix included a deliberate, breaking change to how much the tool trusts unattended runs by default. Novee’s writeup notes the affected package line had roughly two million monthly installs, which gives a sense of how widely this configuration was already in use.

Gemini CLI — Google’s open-source terminal AI agent built on the Gemini API.

Why Codex got no CVE for the same underlying problem

OpenAI’s Codex (the openai/codex coding agent, not ChatGPT) was drawn into the same research and shared the same underlying weakness, yet it received no CVE at all. The reason is instructive rather than reassuring. The flaw was not a coding bug in the traditional sense. It was a workflow design issue: an automation ran in two passes that shared a single checked-out copy of the repository. A first pass could be tricked, again via instructions smuggled in through an outside contributor’s text, into writing a malicious AGENTS.md file, an instruction file meant to guide the agent’s behavior. A second pass would then load that file and follow it, with no special privileges needed anywhere in the chain.

Codex — OpenAI’s coding agent for software engineering tasks, available via CLI and ChatGPT.

OpenAI’s response was to separate the two passes into independent jobs with independent, non-shared checkouts, and to formally document instruction files like AGENTS.md as an untrusted input surface, something the agent should treat with the same suspicion as a stranger’s comment, not as a trusted configuration. There was no version bump and no CVE because, in the researchers’ framing, this was existing, documented behavior being newly recognized as risky, not a defect that shipped and needed patching. That distinction matters more than it sounds: a CVE numbers a specific bug in a specific product. What Black Hat actually surfaced was a design pattern that can resurface in any tool built the same way, whether or not it ever earns a number.

What responsible disclosure looked like here

The Cybersecurity and Infrastructure Security Agency (CISA), the US government body that tracks and coordinates response to security flaws, listed no evidence of real-world exploitation of either the Claude Code or Gemini CLI vulnerabilities as of August 7, 2026, according to The Hacker News’ reporting on the disclosure. This was researchers finding the pattern first and disclosing it responsibly, not an active attack already underway. All three vendors patched or mitigated within the standard disclosure window, and none of it required any end user to have made a mistake. The exposure came from the ordinary, default behavior of connecting coding agents to pipelines that process public, unauthenticated input, which is exactly what most teams do when they let one triage GitHub issues automatically.

What this changes about connecting an agent to your pipeline

The specific CVE numbers, CVSS scores, and patched version numbers in this piece will age quickly, as they always do. What should not age is the question they point to: when you connect a coding agent to automation, you are making a decision about a trust boundary, not just installing a convenience. The software will read whatever the pipeline hands it, and unless the tool and its workflow are explicitly designed to separate trusted instructions from untrusted content, a stranger’s text can end up steering it. That is the same boundary problem behind a wider pattern in software supply chain attacks, where the danger rarely comes from a system being broken into directly, but from something already inside the pipeline being trusted more than it should be. The same question of which framework actually governs that trust boundary, and in what order, is worth working through separately: see how OWASP, MITRE, and NIST divide up AI security responsibilities.

The practical takeaway is not to avoid AI coding agents in CI. It is to treat every piece of content one can reach from outside your organization, an issue, a comment, a config file, as input to be handled carefully, not instructions to be obeyed, and to check that your specific tool’s workflow actually enforces that separation rather than assuming it does.

Frequently asked questions

What is a coding agent, in plain terms? A coding agent is software that reads a request, decides what code or commands are needed, and carries them out automatically, often inside a pipeline that runs without a human present. Claude Code, Gemini CLI, and Codex are all built to work this way, which is exactly why untrusted input reaching them matters.

What is prompt injection, and why does it matter here? Prompt injection is when hidden or disguised instructions inside ordinary-looking content, like a GitHub issue, get treated by an AI system as commands to follow rather than text to read. It matters because it lets an attacker with no account privileges influence what an automated tool does, simply by writing the right words somewhere it will look.

Do I need to stop using Claude Code, Gemini CLI, or Codex in automation? No single tool here is uniquely broken; all three vendors patched or mitigated the issues found, and CISA found no evidence of real-world exploitation. The sensible response is checking your specific setup, not abandoning the category, since the underlying pattern can appear in any agent connected the same way.

Why did Codex not get a CVE if the flaw was just as real? A CVE numbers a specific bug in a specific product version. The Codex issue was a workflow design problem, sharing one checkout across two automation passes, rather than a coding defect, so OpenAI fixed the workflow and documented the risk instead of issuing a patch tied to a version number.

What should I actually check if I run one of these agents in CI? Confirm you are on a patched version of the specific product, check whether instruction files and untrusted content are isolated from privileged steps in your pipeline, and avoid architectures where a single pass can both receive public input and take privileged actions in the same run.

The takeaway

Three vendors, three different technical root causes, one identical opening: a coding agent inside an automated pipeline that could not separate a stranger’s words from a legitimate command. That is the durable lesson here, and it will outlast every patch version in this piece. Anyone running an AI coding agent in CI should treat the boundary between “content the software reads” and “instructions it obeys” as the thing to verify, not assume, because that boundary, not any single vendor’s bug, is what a total stranger walked through three times in a row.