A GitHub issue with zero repo privileges can run code on Anthropic and Google CI runners — Black Hat 2026 tears apart coding agent trust

August 5, 2026. The Black Hat USA stage in Las Vegas. Novee Security researcher takes the mic and demonstrates an attack so simple it feels like cheating: a GitHub account with zero write privileges — the kind any random internet user can create — opened an issue on the official repository of Claude Code (Anthropic). The issue contained a payload. The LLM read it. The LLM executed it. Code ran on Anthropic’s CI runners.

The researcher repeated the attack on Gemini CLI (Google). Same result. On OpenAI Codex, the outcome was even worse: not just code execution, but the ability to hijack the next agent run entirely. Three coding agents, three vendors, one universal vulnerability. All in their default, out-of-the-box configuration.

Three steps from zero to RCE

The attack chain is so minimal it barely qualifies as a chain:

1. Open a GitHub issue. An external account files an issue on the coding agent’s public repo. The title or body contains a prompt designed to trick the LLM into executing code. No special formatting needed — natural language works fine.

2. The coding agent reads the issue. Claude Code, Gemini CLI, or OpenAI Codex treats the ticket as a legitimate task. The underlying LLM parses the content, generates a response — and in the process, executes the embedded instructions.

3. Code runs on the CI runner. The payload executes inside the repository’s CI environment. That environment holds build secrets, deployment tokens, container registry credentials, and — critically — the signing keys that downstream projects trust.

Why this is worse than a standard CI RCE

A remote code execution on a CI runner is bad. An RCE on the CI runner of a tool that thousands of developers trust to write and ship their own code is in a different league entirely.

The Novee Security researcher, whose talk was titled “Your AI Co-Worker Is Also Your Attack Surface,” laid out three systemic failures:

• Implicit trust. Coding agents treat GitHub issues as legitimate inputs by default. The assumption that an LLM would refuse to execute code found in a ticket simply never entered the design spec — and it was wrong.
• No sandboxing. None of the three agents isolate code execution triggered by an issue. The code runs in the same environment as CI secrets and persisted state.
• Amplification effect. Compromising a coding agent’s repository is a force multiplier. Every project that depends on the agent — as a library, a build tool, or a CI template — inherits the risk.

Vendor responses

Anthropic and Google shipped fixes within 48 hours of coordinated disclosure. OpenAI acknowledged the vulnerability and expects to deploy a patch by August 11, 2026.

All three also announced structural changes:

• Mandatory sandboxing for any code execution triggered by an external ticket.
• Least-privilege token policies for CI tokens used by agents.
• Mandatory human review for PRs generated from issues opened by accounts with no contribution history.

What to fix in your own pipeline — today

This isn’t just Anthropic’s or Google’s problem. If your organization runs a coding agent wired into a CI/CD pipeline, the same architectural blind spot exists in your infrastructure.

Audit your CI configuration immediately:

• Isolate runners. Workflows triggered by issues or issue_comment events must run on dedicated, sandboxed runners with zero access to production secrets.
• Sandbox every LLM-driven code execution. Ephemeral containers, no outbound network access, no sensitive volume mounts.
• Scope your tokens. CI tokens used by coding agents must have the minimum possible scope — read-only on the repository, never deployment environment access.
• Require human approval. No agent-generated PR merges without a human reviewer in the loop.

For GitHub Actions users, add this guard to every sensitive workflow:

on:
  issues:
    types: [opened]
jobs:
  process-issue:
    if: github.event.sender.type == 'User' && github.event.sender.site_admin != true
    runs-on: [self-hosted, sandboxed]
    environment: issue-processing  # isolated, no production secrets

Bottom line

The vulnerability exposed at Black Hat 2026 isn’t a bug — it’s an architectural blind spot. Coding agents were built to trust their native ecosystem, and GitHub Issues are part of that ecosystem. Until every LLM-driven code execution is sandboxed by default, every new input surface — issues, comments, PR reviews — becomes an attack vector waiting to be exploited.

If you’re running a coding agent in CI/CD, treat every external input as untrusted code. It’s the only posture that holds.

References

• Novee Security, “Your AI Co-Worker Is Also Your Attack Surface,” Black Hat USA, August 5, 2026
• The Hacker News, “Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets,” August 7, 2026
• GitHub Docs — Security hardening for GitHub Actions