Researchers showed that a single public GitHub issue (from someone with no repo access) could steer popular AI coding agents into running dangerous commands, exposing tokens, and changing repositories. The risk comes from AI agents reading untrusted issue/PR text while also having access to command-line tools and repo credentials. The report describes controlled proof-of-concepts affecting Claude Code, Gemini CLI, and OpenAI Codex workflows, especially in automated/headless setups.
Key findings
- A public GitHub issue/PR can carry attacker instructions that an AI coding agent may follow during automated repo workflows.
- Claude Code could be induced to run a specially prepared git push that abused Git options to execute code on a GitHub Actions runner, potentially exposing GitHub and vendor API tokens.
- Claude Code also had a data-theft path via pre-approved Hugging Face access (CVE-2026-54316), where stolen data could be encoded into requests to an attacker-controlled repo and reconstructed via download-count monitoring.
- Gemini CLI’s intended command restrictions could be bypassed; secrets remained in the parent process and could be read via Linux /proc, exposing tokens and API keys (CVSS 10.0).
- OpenAI Codex workflows could be made persistent by writing an AGENTS.md file that later runs treat as trusted instructions, enabling cross-run influence.
- The report states proof-of-concept testing and does not report real-world malicious exploitation; fixes/mitigations are available but similar workflows in other orgs may remain vulnerable.
Who’s being targeted
- Commonly targeted roles: Developers, Repository maintainers, DevOps / CI-CD engineers, Security engineering / AppSec.
- Affected industries: Software development, DevOps / CI/CD operations, Open-source maintainers, Technology vendors, Any organization using AI coding agents with GitHub Actions.
- Attack channels: github, email.
- Impersonated: External contributor / bug reporter (untrusted GitHub user), External contributor / issue author.
Awareness takeaways
- Treat public issues/PRs as untrusted input, never let issue text directly drive automated commands without strict safeguards.
- Lock down CI/CD tokens and reduce permissions; assume any workflow step that executes commands could expose credentials.
- Prevent “persistence” between AI agent runs by isolating workspaces (separate jobs/checkouts) and using read-only environments where possible.
- Patch and validate configurations for AI coding agents used in headless automation that processes untrusted content.
Red flags to watch for
- Untrusted issue text contains operational commands to run
- Requests to run unusual git options/commands as part of issue triage
- Workflow runs with tokens/credentials available to the agent
- “Diagnostics” request includes steps that inspect `/proc` or process environments
- Assumption that command restrictions are enforced without verifying runtime controls
- Headless automation processing untrusted issue/PR content
- Instructions to create governance/config files during issue triage without review
- Multiple agents sharing the same writable workspace between runs
- “Project instructions” file changes coming from untrusted inputs
Read the video transcript
Imagine a random GitHub user opens an issue, and that text quietly makes your AI agent run git commands with your tokens. Researchers showed Claude Code, Gemini CLI, even OpenAI Codex-style workflows could read a public issue and then run a 'safe' git push that abuses Git’s receive-pack, hits GitHub Actions, and leaks GitHub and API tokens. One nasty twist: a single issue could tell Gemini CLI to 'run diagnostics', then use /proc to read the parent process and dump your GitHub token, Gemini API key, everything, no repo access needed, just text. Here’s the move: if your AI tools touch GitHub with tokens, treat every public issue and PR as hostile input, never let their text auto-drive commands without strict review.