Safeguard
AI Security•

One GitHub issue, three coding agents: Novee's Black Hat CI findings

At Black Hat on 5 August 2026, Novee showed an unprivileged GitHub issue reaching CI secrets through Claude Code, Gemini CLI and OpenAI Codex workflows.

Safeguard Security Team
6 min read

On 5 August 2026, Novee Security presented research at Black Hat USA showing that an unprivileged GitHub issue could reach secrets in CI pipelines that run AI coding agents. Three vendors were involved: Anthropic's Claude Code, Google's Gemini CLI and OpenAI's Codex. Two got CVEs, CVE-2026-54316 and CVE-2026-12537, and Codex was fixed by changing how its own repository workflow was built.

No widespread exploitation was confirmed at disclosure. The proofs of concept were controlled tests, and Novee reports finding comparable configurations in more than 100 public repositories.

What's affected

Claude Code. CVE-2026-54316, versions 0.2.54 up to but not including 2.1.163, fixed in 2.1.163. A pre-approved huggingface.co destination in WebFetch let an agent encode stolen data into requests to an attacker-controlled repository. Hackread's account of the talk also describes an earlier route through a crafted git push that abused Git's receive-pack option, which Anthropic blocked. We covered the CVE on its own in a separate post.

Gemini CLI. CVE-2026-12537, CVSS 10.0, in npm @google/gemini-cli before 0.39.1 (and exactly 0.40.0-preview.2), and in the google-github-actions/run-gemini-cli action before 0.1.22. The advisory names two problems:

  1. In headless CI mode, earlier versions automatically trusted workspace folders. A malicious .env or .gemini/ directory in an untrusted checkout could lead to code execution.
  2. In --yolo mode, earlier versions ignored fine-grained tool allowlists, so an allowlist permitting run_shell_command could be abused through prompt injection.

Fixed versions are 0.39.1 and 0.40.0-preview.3 for the CLI, and 0.1.22 for the action. The advisory says it affects all Gemini CLI GitHub Actions. Credits go to Elad Meged of Novee Security and Dan Lisichkin of the Pillar Security research team. Novee's account, via Hackread, adds that secrets removed from child processes remained readable in the parent process through /proc.

OpenAI Codex. No CVE and no version. An issue-deduplication workflow ran two agents in the same writable workspace. The first could be manipulated into creating an AGENTS.md file, and the second accepted it as trusted instructions. Influence crossed the boundary even though the workflow rejected the first agent's direct output. OpenAI separated the runs into different jobs and checkouts, then moved them to read-only environments, within three days. OpenAI said its sandbox "operated as documented."

At a glance

AgentIdentifierAffectedFix
Claude CodeCVE-2026-543160.2.54 to before 2.1.1632.1.163
Gemini CLI (npm)CVE-2026-12537before 0.39.10.39.1, 0.40.0-preview.3
run-gemini-cli (Action)CVE-2026-12537before 0.1.220.1.22
OpenAI Codexnonerepository workflow designjobs and checkouts separated, read-only

The common thread is not a single bug. PointGuard's summary of the research lists the shared causes: inherited environment secrets, overbroad repository tokens, unsafe configuration loading and permissive outbound access.

How to check if you're exposed

Find every workflow that runs an agent on content strangers can write:

grep -rlE "claude-code|run-gemini-cli|gemini-cli|codex" .github/workflows/
grep -rnE "issues:|issue_comment|pull_request_target" .github/workflows/ | head -40

Then check versions and trust settings:

grep -rnE "gemini_cli_version|run-gemini-cli@|GEMINI_TRUST_WORKSPACE" .github/workflows/
grep -rn "yolo" .github/workflows/ ~/.gemini/settings.json 2>/dev/null

For each hit, write down three things: what text from outside the team reaches the agent, which secrets the job can read, and what token permissions the job has.

What to do now

  1. Upgrade Claude Code to 2.1.163 or later, Gemini CLI to 0.39.1 or later, and run-gemini-cli to 0.1.22 or later.
  2. For Gemini workflows, set GEMINI_TRUST_WORKSPACE: 'true' only when inputs come from trusted collaborators. For untrusted inputs, follow the hardening guidance in the run-gemini-cli repository first, as the advisory says. Expect some pipelines to need updated tool allowlists after the upgrade.
  3. Never let two agent passes share a writable directory. If pass two reads files pass one wrote, pass one controls pass two.
  4. Reduce GITHUB_TOKEN permissions in agent jobs to the minimum, and keep release or publish credentials in a separate job.
  5. Add approvals for sensitive writes, releases and credential use.

How this could have been avoided

  • Trust no workspace by default in headless mode. Gemini CLI trusted folders automatically in CI, so an attacker's checkout configured the tool. Explicit trust, now required, closes it.
  • Separate agent passes into separate jobs and checkouts. The Codex flaw was shared writable state. Different jobs with read-only environments remove the shared file.
  • Strip secrets before the agent starts, not after. If a secret exists in the parent process, a child shell can reach it. Pass the agent only what it needs, using job-level environment scoping.
  • Use least-privilege repository tokens. The impact in Novee's research ranged up to workflow changes and altered packages, depending on token permissions.
  • Limit outbound network access from runners. Hosts approved for convenience became exfiltration routes in the Claude Code case.

Why it matters

A public issue tracker is an open text box that your pipeline now reads with a program that can run commands. Every agent in this research behaved as designed, and the failures came from configuration: trust granted automatically, state shared between steps, domains approved broadly, secrets present everywhere.

The Codex outcome is worth noting because it had no CVE. A scanner looking for vulnerable versions would find nothing. Only a review of how the workflow was wired, who can write what, and where output flows would catch it.

Think of an agent job the way you would think of a build that runs a contributor's pull request. You would not give that build your publishing keys. The same rule applies here.

Try it yourself

Open one agent-driven workflow in your repository. Draw the path from a stranger's text to a command execution, then mark every secret and token on the path. The demo below walks through CI/CD controls on a pipeline.

Click through it at your own pace, or open it full screen.

Quick check

Which Gemini CLI and run-gemini-cli versions fix CVE-2026-12537?

Gemini CLI 0.39.1 (or 0.40.0-preview.3 on the preview track) and the run-gemini-cli action 0.1.22.

Why did the Codex finding have no CVE, and why does that matter?

It was a workflow design problem in a repository, where one agent wrote an AGENTS.md file that a second agent trusted. Version scanning cannot find it, so only a configuration review will.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.