One GitHub Issue Can Now Hijack Your CI Pipeline

At Black Hat USA on August 5, security researchers showed something that should worry every engineering team running an AI coding agent: a GitHub issue opened by an account with zero repository privileges was enough to execute code on the CI runners behind Anthropic's and Google's own coding-agent repositories. On OpenAI's, the same trick was enough to hijack the next agent run. No stolen credentials, no phishing, no insider. Just a plain-text issue that a human reviewer would glance at and dismiss, but that the AI agent read, interpreted as instructions, and acted on inside a pipeline that already held real secrets. Two CVEs came out of the disclosure — one scoring a maximum 10.0 on the CVSS scale — and researchers demonstrated the same underlying pattern working across Claude Code, Gemini CLI, and OpenAI Codex, not just one vendor's implementation.

This isn't a new category of bug. It's the same one security researcher RyotaK disclosed in Anthropic's Claude Code back in January: open an issue, let the agent read it, watch it hand over write credentials to the repo. What changed by August is the scale of the demonstration — three major vendors, production CI environments, and a name for the underlying failure that's easy to explain to a non-security person: an AI coding agent sitting in your pipeline is simultaneously reading untrusted text from the public internet, holding the authority to change your codebase, and able to talk to external systems. Security researchers call the fix for that combination the "Agents Rule of Two" — never let one workflow hold all three capabilities at once — and most teams that adopted an AI coding agent in the last year never heard of the rule, let alone checked whether their setup violates it.

Why This Is Worse Than a Normal CI Vulnerability

A traditional CI vulnerability usually needs an attacker with some level of access already — a compromised dependency, a leaked token, a malicious contributor with merge rights. This one doesn't. The Black Hat research and a related "Comment and Control" study both point to the same structural problem:

• Zero privilege required. Filing a GitHub issue or leaving a comment is available to any free GitHub account — the attacker needs no repo access, no prior relationship with the target, nothing but a text box.
• The agent is the attack surface, not the codebase. The malicious payload isn't a code change a reviewer might catch in a diff — it's instructions embedded in an issue title or comment that the agent reads as part of doing its job.
• CI runners hold real secrets by design. Deploy keys, package registry tokens, cloud credentials — the same access an AI coding agent needs to be useful in a pipeline is exactly what an attacker wants once the agent is compromised.
• It scales without new effort. A single prompt-injection pattern worked across Claude Code, Gemini CLI, and Copilot Agent in the cross-vendor research — an attacker doesn't need a bespoke exploit for each tool your team happens to use.

The Governance Gap Nobody's Checking

Most small and mid-sized engineering teams adopted an AI coding agent the way they'd adopt any dev tool: install it, connect it to the repo, let it start opening PRs. Almost none went through a security review first, because the tool felt like autocomplete, not like a new identity with write access and internet-adjacent behavior sitting inside the pipeline. That gap is exactly what this research exploits. The fix isn't abandoning AI coding agents — the productivity case for them is real and not going away — it's treating the agent's CI integration with the same scrutiny you'd give a new service account:

1. 1Audit which of your CI workflows let an AI agent both read untrusted input (issues, PR descriptions, comments) and reach a runner with production secrets — that combination is the entire attack surface
2. 2Apply the Agents Rule of Two directly: if a workflow needs to process untrusted content, it shouldn't also hold write access or the ability to call external tools in the same run
3. 3Scope CI credentials tightly to what each specific agent task needs, instead of a broad token the agent (and anything that hijacks it) can use for anything
4. 4Patch immediately against the disclosed CVEs if you're running Claude Code, Gemini CLI, or Codex in CI — the vendors shipped fixes, but a fix only helps if it's applied
5. 5Treat every issue, comment, and PR description as untrusted input to the agent, not just untrusted input to a human reviewer, and design the pipeline accordingly

A Realistic Scenario

A mid-sized SaaS company had wired an AI coding agent into its CI pipeline six months earlier to auto-triage and respond to GitHub issues — genuinely useful, and it cut first-response time on bug reports significantly. Nobody had reviewed the setup since. The agent's CI workflow held a broadly scoped deploy token, read every incoming issue automatically, and could open pull requests without a human gate. When Wizeb audited the pipeline after this disclosure, the finding was almost a textbook match for the Black Hat research: an anonymous account could open an issue with embedded instructions, the agent would read it as part of its normal triage behavior, and the workflow's token scope was broad enough that a successful injection could have reached the deploy pipeline. Nothing had been exploited yet — but the exposure had existed, unnoticed, for the full six months the integration had been live. The fix took an afternoon: split the triage workflow from anything holding deploy credentials, scope tokens per task, and add an explicit human approval gate before any agent-originated change could merge.

How Wizeb Approaches This

When we deploy or audit an AI agent for a client — coding agent or otherwise — the integration gets reviewed the same way a new privileged service account would: what untrusted input can it read, what can it change, what can it talk to, and does any single workflow combine all three. That's the Agents Rule of Two applied as a checklist, not a slogan. If your team has an AI coding agent wired into CI and nobody's specifically checked it against this class of vulnerability since it went live, that's typically a half-day audit, not a rebuild. Start at wizeb.com/services/ai-agents.

Three Questions Before Your Next Deploy

1. 1Does any CI workflow let your AI coding agent read untrusted text (issues, comments, PR titles) and also reach credentials that can deploy or publish?
2. 2If an attacker opened an issue today with hidden instructions, would your agent's pipeline execute them, or is there a human gate in the way?
3. 3Are you running Claude Code, Gemini CLI, or Codex in CI on the vendor's default configuration — and have you actually confirmed the disclosed CVEs are patched?