Prompt-Injection PR Trick Leaks Repo Secrets

How the attack worked

A researcher demonstrated that AI coding agents wired into GitHub workflows can be manipulated through a pull request description alone. The PR text looks like a routine bug report asking for a few diagnostic shell commands to be run and the output pasted back. Because the agent processes this untrusted text before any human reviews it, it extracts the embedded commands, gets them approved as "safe," executes them, and then automatically posts the results back into the public PR thread. If those results include secrets, they are exposed to anyone with visibility into the repository.

Why it succeeded

The scenarios tested against default and recommended configurations from three major agent vendors show the weakness is not the prompt injection itself, it is how the automation pipeline, or harness, handles trust across stages. One stage approves a command as safe. A later stage publishes the output by default. Neither stage re-checks the other's assumptions, so approval and publication combine into an exfiltration chain. In one case, a documented CI configuration recommended for processing untrusted input still failed because a configured restriction was not enforced at the point of execution, a finding that produced a maximum-severity advisory.

What to watch for

• Untrusted pull request or issue text being treated as executable instructions by an automated agent
• Command output posted automatically to a public thread or log without review for sensitive data
• Multi-stage workflows where state written in one stage is consumed as trusted context by a later, more privileged stage
• Reliance on "recommended" security configurations without verifying they are enforced at runtime
• Protected path or restriction lists that assume a fixed set of risks while ignoring attacker-influenced state elsewhere

How to build resistance

Organizations using AI coding or CI agents should treat all externally supplied text, including PR descriptions, as hostile input rather than as instructions to execute. Automatic posting of command output to PR threads or logs should be disabled or tightly gated, since output may contain secrets that were never meant to be shared. Most importantly, trust should be re-validated at the point of consumption, such as execution or publishing, rather than assumed to carry over from an earlier approval decision. Teams should specifically trace every path where agent output or agent-influenced state gets picked up by a later stage with different privileges, since that handoff point is where these defenses have repeatedly failed in testing.

How does a malicious pull request lead to a secret leak?

A pull request description can contain text that an AI agent parses as instructions, extracting shell commands, getting them approved as safe, and then automatically posting the command output back into the PR thread, which can expose secrets.

Is this a flaw in the AI model or the surrounding automation?

The research found the core issue was not the prompt injection itself but how the agent's automation pipeline, or harness, approves steps and publishes outputs across workflow stages without re-checking trust at each handoff.

Which vendors were affected by this issue?

The testing covered default and recommended configurations of agent tooling from Anthropic, Google, and OpenAI, including a CVSS 10.0 advisory tied to Google's Gemini CLI and a sandbox bypass issue in OpenAI's Codex CLI.

What should teams do to reduce this risk?

Teams should treat pull request text as hostile input, tightly control automatic posting of command output, and re-validate trust at the point of execution or publishing rather than only at the initial approval step.