Gemini CLI TrustIssues
Prompt Injection to Supply-Chain Compromise in Agentic CI
Pillar Security disclosed GHSA-wpqr-6v78-jr5g on May 5, 2026 — a maximum-severity vulnerability in Google's Gemini CLI that allows an external attacker to escalate from a public GitHub issue to complete supply-chain compromise of a repository. The attack exploits how Gemini CLI's --yolo mode ignores tool allowlists while processing untrusted content, enabling a prompt-injected GitHub issue to extract CI secrets and gain repository write access. No privileged access is required — a public issue is the only entry point.
"A supply-chain attack via indirect prompts injected into a GitHub issue. The agent reads the issue, follows the instructions, and the repository is compromised."
— SecurityWeek coverage of GHSA-wpqr-6v78-jr5g
Advisory Details
Gemini CLI Prompt Injection via --yolo Mode Tool Allowlist Bypass in Agentic CI/CD Workflows
@google/gemini-cli before 0.39.1 / 0.40.0-preview.3 and google-github-actions/run-gemini-cli before 0.1.22 allow prompt injection through untrusted content (GitHub issues, pull request bodies, code comments) processed by agentic CI workflows. When running in --yolo mode, the CLI auto-approves all tool calls and ignores configured tool allowlists, giving injected instructions access to file reads, shell execution, secret exfiltration, and Git operations — including repository write access.
ROOT CAUSE — THE LETHAL TRIFECTA
Pillar Security identified the central defect as --yolo mode auto-approving all tool calls while bypassing fine-grained tool allowlists. This is exploitable because CI/CD pipelines naturally contain all three conditions of the "lethal trifecta": (1) access to private data — CI secrets, GITHUB_TOKEN, GEMINI_API_KEY, persisted credentials; (2) exposure to untrusted content — public issues, PR bodies, code comments; (3) ability to communicate externally — network egress for exfiltration. When all three conditions coexist in a single workflow, prompt injection becomes supply-chain compromise.
RELATED: HEADLESS MODE WORKSPACE TRUST
A separate vulnerability discovered by Novee Security and addressed in the same patch cycle: Gemini CLI in headless mode automatically trusted workspace folders and could load attacker-controlled configuration and environment variables before sandbox initialization completed. This allowed a malicious repository to influence agent behavior from first execution, before any tool allowlists were applied.
Attack Path
Attacker Opens a Public GitHub Issue
The attacker opens a GitHub issue in any repository running a Gemini-powered triage or labeling workflow. No repository access or prior authentication is required — public repositories accept issues from any GitHub account. The issue body contains prompt-injection instructions embedded alongside plausible bug report text.
The injection can be using Unicode whitespace, HTML comments, or content after a visible section break — techniques that appear normal to human reviewers but are parsed by the AI agent.
Triage Agent Reads the Issue
The repository's CI workflow triggers Gemini CLI to classify, label, or respond to the new issue. The agent ingests the full issue body as context — including the attacker's injected instructions. From the agent's perspective, the instructions are indistinguishable from legitimate workflow directives.
Triage workflows commonly have access to GITHUB_TOKEN, GEMINI_API_KEY, and persisted Git credentials — all the permissions needed for the next steps.
--yolo Mode Bypasses Tool Allowlists
The workflow runs Gemini CLI with --yolo mode enabled for unattended operation. In this mode the CLI auto-approves all tool calls and ignores configured allowlists. The injected instructions can now invoke file reads, shell commands, environment variable access, and Git operations without any approval gate or scope restriction.
Tool allowlists are the intended safety boundary for autonomous operation. --yolo mode silently voided this boundary in affected versions.
Secret Extraction, Exfiltration, and Repository Write Compromise
With unrestricted tool access, the agent follows the injected instructions to read CI secrets from environment variables, exfiltrate them to attacker-controlled infrastructure, and pivot to workflows with elevated permissions. Using stolen credentials, the attacker gains repository write access — enabling arbitrary code commits, workflow modification, release tampering, or downstream package compromise.
Multiple Google repositories reportedly contained vulnerable workflow patterns. A single compromised upstream repository can propagate malicious code to every downstream consumer of that package.
Impact
CI Runner Secrets
- GEMINI_API_KEY exfiltration
- GITHUB_TOKEN theft and misuse
- OIDC credential abuse
- Persisted checkout credentials
Repository Control
- Arbitrary code pushed to main branches
- Workflow modification and backdooring
- Release pipeline tampering
- Malicious commits before review gates
Supply-Chain Downstream
- Compromised packages shipped to consumers
- Vulnerable workflow templates replicated across repos
- Enterprise pipelines inheriting unsafe AI triage patterns
- Trust erosion in affected open-source ecosystems
Response Checklist
Upgrade @google/gemini-cli to 0.39.1, 0.40.0-preview.3, or later. Upgrade google-github-actions/run-gemini-cli to 0.1.22 or later. Pin both to a specific version tag in all workflow files — floating references allow silent regression if the action is republished.
Search all repositories for GitHub Actions workflows that invoke Gemini CLI, especially those triggered by issues, pull_request, issue_comment, or pull_request_review_comment events. These events process untrusted public content and are the primary injection surface.
Remove --yolo from any workflow that ingests untrusted external content — issues, PRs, comments, or user-submitted text. If unattended operation is required, replace --yolo with an explicit, minimal tool allowlist scoped to only the tools the workflow legitimately needs.
For any workflow that ran a vulnerable Gemini CLI version with --yolo mode enabled, treat all accessible credentials as potentially compromised: GEMINI_API_KEY, GITHUB_TOKEN, OIDC tokens, cloud provider credentials, and any secrets stored in the Actions secrets store.
Set the minimum required permissions on every workflow invoking Gemini CLI. A triage workflow should not have contents: write or packages: write. Add an explicit permissions: block to every workflow file — GitHub defaults to broad permissions when the block is absent.
Set persist-credentials: false in actions/checkout for any job that does not require write-capable Git credentials on disk. Persisted credentials are a high-value target for prompt-injected exfiltration and are unnecessary for read-only triage workflows.
AI issue triage and privileged release or write workflows must not share a trust boundary. A compromised triage step should not be able to trigger deployments, push commits, or invoke workflows with elevated permissions. Enforce this through separate jobs with distinct permission scopes and explicit approval gates between triage output and write operations.
Pin google-github-actions/run-gemini-cli and all other third-party actions to a specific commit SHA rather than a floating version tag. Configure Gemini CLI in headless mode to require explicit workspace trust rather than auto-trusting the current directory — this addresses the related Novee Security workspace-trust vulnerability in the same patch cycle.
Governance Framework
Threat-Model Agentic CI
For every workflow containing an AI agent, answer three questions before deployment: (1) what untrusted content can the agent read? (2) what private data can it access? (3) where can it send data? If all three conditions exist in the same job, the workflow requires isolation, egress control, and explicit approval gates.
Explicit Tool Allowlists
Define the exact set of tools each agentic workflow is permitted to invoke, and enforce that list at the runtime level — not through documentation. Auto-approve modes (--yolo) must never bypass allowlists; they should only remove the human confirmation prompt for already-allowlisted tools.
Least-Privilege CI Permissions
Every workflow that processes untrusted external content should run with the minimum permissions required for its specific task. Triage workflows are read-only by nature — they should never inherit write permissions from repository defaults.
Credential Isolation
Secrets accessible to AI-powered workflows should be scoped to the workflow's actual requirements. High-value credentials (deploy keys, release tokens, cloud provider access) must not be co-located in jobs that ingest untrusted content. Use separate jobs with distinct secret scopes and explicit handoff gates.
Egress Control
Agentic CI jobs that process untrusted content should not have unrestricted network egress. Allowlist outbound destinations and log all external calls. Unexplained external requests from an agentic job are a strong signal of active prompt injection.
Prompt-Injection Testing
Include prompt-injection scenarios in security reviews for every CI workflow that uses an AI agent. Test whether a crafted GitHub issue, PR body, or code comment can steer the agent to perform actions outside its intended scope. Treat injection resistance as a required property, not an afterthought.
References
[1] Pillar Security
"My Agentic Trust Issues: From Prompt Injection to Supply-Chain Compromise on gemini-cli" — Primary researcher disclosure, May 5, 2026.
[2] GitHub Security Advisory
GHSA-wpqr-6v78-jr5g — Gemini CLI prompt injection via --yolo mode tool allowlist bypass. Google initial advisory April 24, 2026.
[3] The Hacker News
"Google Fixes CVSS 10 Gemini CLI CI RCE and Cursor Flaws Enable Code Execution" — April 30, 2026.
[4] SecurityWeek
"Gemini CLI Vulnerability Could Have Led to Code Execution, Supply Chain Attack" — May 7, 2026.
[5] The Register
"Google's fix for critical Gemini CLI bug might break your CI/CD pipelines" — April 30, 2026.