Gemini CLI 'TrustIssues' — a public GitHub issue reaches CI secrets via --yolo mode tool-allowlist bypass (CVE-2026-12537, CVSS 10.0)

View raw markdownEdit on GitHub ↗

TL;DR

Google's Gemini CLI, when run in --yolo mode inside a headless CI workflow (the pattern run-gemini-cli uses to auto-triage user-submitted GitHub issues), ignored its own tool allowlist and auto-approved every tool call. An attacker who could open a public GitHub issue — no repository access, no account history required — could hide prompt-injection instructions in the issue body, have Gemini CLI's triage agent read them, and walk the agent through extracting CI build-environment secrets to an attacker-controlled server. A related OS-command-injection bug in the container launcher (reached via a crafted .gemini/.env file) allowed pre-sandbox, host-level code execution on the CI runner itself. Both were fixed together in Gemini CLI 0.39.1 / run-gemini-cli 0.1.22 on 2026-04-24; the underlying CVE (CVE-2026-12537, CVSS 10.0) was assigned afterward and only drew broad security-press coverage in August 2026, when the researchers paired it with an already-patched Claude Code finding in a Black Hat USA 2026 talk. This repo had not previously tracked either bug.

What happened

Security researchers Elad Meged (Novee Security) and Dan Lisichkin (Pillar Security) — publishing jointly as "My Agentic Trust Issues" — found that Google's own reference workflow for auto-triaging GitHub issues with Gemini CLI (run-gemini-cli, deployed on at least eight other Google repositories using the same template) ran the agent with --yolo mode enabled, a flag meant for trusted local use that disables Gemini CLI's tool-call allowlist entirely.

Attack chain: 1. An attacker opens a public GitHub issue on a repository running the vulnerable run-gemini-cli triage workflow — no write access or prior interaction with the repo required. 2. The issue body contains hidden prompt-injection instructions, disguised as part of a normal bug report. 3. Gemini CLI's automated triage agent reads the issue to summarize/label it. Because --yolo mode auto-approves every tool call, the injected instructions can direct the agent to read CI environment variables, secrets files, or other build-environment material and exfiltrate them to an attacker-controlled endpoint — with no approval prompt and no allowlist check at any point in the chain.

Second, related bug — container-launcher OS command injection (CVE-2026-12537). Separately, Gemini CLI's container launcher was vulnerable to OS command injection via a crafted .gemini/.env file: on a headless CI platform, this file was interpreted as legitimate configuration and could execute attacker-controlled commands on the host, before the sandbox was even applied — meaning the same untrusted-repository-content path (a malicious PR or issue-triggered checkout) could achieve host-level code execution independent of the --yolo/allowlist bug above. CVSS 10.0 (v4).

Google patched both together in Gemini CLI 0.39.1 and run-gemini-cli 0.1.22 on 2026-04-24, evaluating tool allowlisting correctly under --yolo mode and closing the .env-based container-launcher injection.

Why this repo missed it for four months. The April 2026 disclosure (Pillar Security's own blog, SecurityWeek, HackRead, CyberPress) drew only modest coverage and this repo's Tier-A/B rotation for "Gemini CLI" specifically wasn't yet part of the standing query set at the time. It resurfaced broadly in security-press coverage on 2026-08-05/07 when Novee Security presented it at Black Hat USA 2026 alongside a different, already-tracked Claude Code bug — CVE-2026-54316, out-of-band exfiltration via a pre-approved HuggingFace domain in WebFetch, patched in Claude Code 2.1.163 back in June 2026 — under the shared framing "a GitHub issue reaches CI workflow secrets." The Claude Code half of that pairing was already in this repo; the Gemini CLI half (CVE-2026-12537) was not.

Am I affected?

# Check your installed Gemini CLI / run-gemini-cli versions
npx @google/gemini-cli --version
npm ls run-gemini-cli 2>/dev/null

You're exposed if: - You run @google/gemini-cli < 0.39.1 or run-gemini-cli < 0.1.22, AND - Any CI/CD workflow (issue triage, PR review, automated labeling) invokes Gemini CLI with --yolo mode against content that untrusted, unauthenticated users can influence (public GitHub issues, PR titles/bodies, comments), OR the workflow runs on a headless platform where a .gemini/.env file from an untrusted checkout could be read before your sandbox applies.

If you are affected

  1. Upgrade to @google/gemini-cli ≥ 0.39.1 and run-gemini-cli ≥ 0.1.22 immediately.
  2. Audit every CI workflow that invokes Gemini CLI against user-triggerable content (issues, PRs, comments) — confirm --yolo mode is not enabled for any workflow that processes untrusted input.
  3. Rotate any CI/CD secrets, API keys, or tokens that were reachable from a workflow matching the vulnerable pattern before 2026-04-24.
  4. Audit GitHub Actions logs for triage-workflow runs triggered by issues/PRs from unfamiliar or low-history accounts around the exposure window.

→ playbooks/if-your-local-ai-agent-was-exploited.md → playbooks/rotating-cloud-credentials.md

Prevention

→ prevention/ci-cd-hardening.md — never run an auto-approve/--yolo-style AI-agent mode against untrusted, externally-triggerable input (issues, PR titles, comments) in CI. → prevention/agent-sandboxing.md - Treat any CI workflow that reads GitHub issue/PR content with an AI agent as processing untrusted input by definition — apply the same tool-allowlist discipline you'd use for a public-facing web form, regardless of what auto-triage convenience flags promise. - Cross-reference with Claude Code's own GHSA batch (CVE-2026-54316) — both bugs were surfaced by the same researcher and share the same "GitHub issue → CI secrets" shape, just through different mechanisms (allowlist bypass vs. pre-approved-domain exfil channel).

Sources