Skip to content

fix(security): document prompt injection risk from ISSUE_BODY in AI agent workflows#529

Open
XananasX7 wants to merge 1 commit into
google-github-actions:mainfrom
XananasX7:fix/security-prompt-injection-issue-body-in-workflows
Open

fix(security): document prompt injection risk from ISSUE_BODY in AI agent workflows#529
XananasX7 wants to merge 1 commit into
google-github-actions:mainfrom
XananasX7:fix/security-prompt-injection-issue-body-in-workflows

Conversation

@XananasX7

Copy link
Copy Markdown

Summary

Documents the prompt injection attack surface in gemini-issue-fixer.yml and gemini-triage.yml where github.event.issue.body (attacker-controlled) is passed directly as ISSUE_BODY into the Gemini CLI execution environment.

Impact

This action is used by ~1,740 repositories (per GitHub code search). The issue affects any consumer repo where the Gemini execution step has access to a write-capable GITHUB_TOKEN.

Attack scenario:

  1. Attacker opens a GitHub issue with a crafted body containing prompt injection payload
  2. The workflow triggers with ISSUE_BODY containing the injected instructions
  3. Gemini CLI receives the attacker's instructions alongside the legitimate prompt
  4. If the Gemini step has GITHUB_TOKEN set, the agent can: create PRs, post comments, modify code

Currently in this repo: The Gemini execution step sets GITHUB_TOKEN: '' (empty) — this is the critical mitigation. However, this is not documented as a security boundary, making it easy for consumers to accidentally add a token without realizing the risk.

What this PR does

Adds explicit security comments to document that:

  1. ISSUE_BODY is attacker-controlled (any GitHub user can open an issue)
  2. Keeping GITHUB_TOKEN empty during Gemini execution is a security requirement, not an oversight
  3. Consumers who set GITHUB_TOKEN in the Gemini step of their own workflows would be vulnerable

Recommendations for a stronger fix

  1. Add a security note to the README/docs warning about prompt injection
  2. Consider wrapping ISSUE_BODY in explicit <untrusted_input> delimiters in the prompt
  3. Add a GitHub Actions input parameter that warns if GITHUB_TOKEN is passed alongside untrusted content
  4. Consider validating/sanitizing prompt context files before passing to Gemini CLI

Affected workflows

  • .github/workflows/gemini-issue-fixer.yml
  • .github/workflows/gemini-triage.yml

…gent workflows

The gemini-issue-fixer.yml and gemini-triage.yml workflows pass
github.event.issue.body (attacker-controlled) directly as ISSUE_BODY
environment variable into the Gemini CLI execution context.

This creates an indirect prompt injection surface: any GitHub user who
opens an issue can craft a body that attempts to manipulate the Gemini
agent's behavior. The agent runs with write-capable GitHub tokens
(contents:write, issues:write, pull-requests:write) and the GitHub MCP
server, so successful injection could lead to:
- Malicious PRs created against the repository
- Issue comments posted with attacker-controlled content
- Repository content modified via the AI agent

Mitigations already present (these must be maintained):
- GITHUB_TOKEN: '' in the Gemini execution step
- Output validation before applying labels
- Template-based responses rather than raw LLM output

This commit adds explicit security comments to document that ISSUE_BODY
is untrusted user input and that maintaining empty GITHUB_TOKEN during
AI execution is a critical security boundary — not an oversight.

Note: This action is used by ~1,740 repositories. Consumers who add
GITHUB_TOKEN to the Gemini execution step would be vulnerable.
@XananasX7 XananasX7 requested review from a team as code owners June 28, 2026 01:43
@google-cla

google-cla Bot commented Jun 28, 2026

Copy link
Copy Markdown

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant