Gemini CLI 'TrustIssues' — a public GitHub issue reaches CI secrets via --yolo mode tool-allowlist bypass (CVE-2026-12537, CVSS 10.0), then returns in August via a deprecated config key and takes a whole GCP project

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).

Update — 2026-08-18: the fix was incomplete. A deprecated config key silently disabled the allowlist, and this time it reached the whole GCP project.

Pillar Security published a second, distinct finding against the same workflow pattern on 2026-08-18. It is the clearest case of this repo's "incomplete fix ≠ patched" pattern in the AI-agent-CI space: the April patch above made the CLI evaluate tool allowlists correctly under --yolo — but only for the current config key. Google's own published setup script still used the deprecated top-level coreTools key, and Gemini CLI 0.46.0 resolves the allowlist solely from settings.tools?.core || undefined. Pillar quotes the codebase directly: "top-level settings.coreTools is never read."

The unrecognized key was not rejected, warned about, or logged — just silently dropped. With the resulting allowlist undefined, the CLI fell back to a wildcard "allow all" rule, which, as Pillar puts it, reintroduced the same CVSS 10.0 RCE that advisory GHSA-wpqr-6v78-jr5g was supposed to close — but only for the deprecated key pattern.

The escalation is worse this time. Where the April bug reached CI build-environment secrets, the August chain reaches full GCP project compromise, in six steps:

  1. An attacker opens a GitHub issue containing a prompt injection (no account privileges needed).
  2. gemini-automated-issue-triage.yml feeds the untrusted issue text to the agent.
  3. The agent runs arbitrary shell commands, because the visible-but-inert "coreTools": ["run_shell_command(echo)", "read_file"] allowlist does nothing.
  4. The injected command reads the plaintext Workload Identity Federation OIDC credentials file, written to a predictable path by the workflow's auth step — Pillar calls it "the token-minting machine."
  5. Those credentials mint real GCP access tokens as the workflow's service account.
  6. setup_workload_identity.sh had granted that account project-level roles/iam.serviceAccountTokenCreator:

bash gcloud projects add-iam-policy-binding "${GOOGLE_CLOUD_PROJECT}" \ --role="roles/iam.serviceAccountTokenCreator" \ --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \ --condition=None

so it can impersonate any service account in the project — including the Compute Engine default service account, which carries Editor.

Timeline: reported to Google VRP 2026-06-11 (accepted same day), initial fixes 2026-06-17, fix verified and publication approved 2026-08-14, bounty issued 2026-08-18. No CVE assigned to this second finding.

Google's three fixes: enforce the allowlist on the correct nested keys (tools.core / tools.allowed); add the OIDC credentials file to .geminiignore so the agent cannot read it; and scope serviceAccountTokenCreator in the updated setup_workload_identity.sh to a single service-account resource instead of a project-wide binding.

The part that does not fix itself. Updating the Action does not revoke an over-broad IAM binding the old script already created. Check it explicitly:

# Deprecated key still present anywhere? This is the silent-failure tell.
grep -rn 'coreTools' .github/workflows/ .gemini/ 2>/dev/null

# Agent running --yolo over input anonymous users control?
grep -rn -- '--yolo\|run-gemini-cli' .github/workflows/ 2>/dev/null

# The project-level binding the old setup script created.
gcloud projects get-iam-policy "$GOOGLE_CLOUD_PROJECT" \
  --flatten='bindings[].members' \
  --filter='bindings.role=roles/iam.serviceAccountTokenCreator' \
  --format='table(bindings.role, bindings.members)'

If that last command shows the role bound at the project level to a CI service account, the escalation path is still open no matter which Gemini CLI version you run.

Were you exploited? Check GCP audit logs for GenerateAccessToken / GenerateIdToken calls (iamcredentials.googleapis.com) from the workflow service account that don't match legitimate runs, Editor-level activity by the Compute Engine default service account, and triage-run logs showing run_shell_command invocations beyond what you believed was allowlisted. Cross-reference against issues filed by accounts with no prior repo history.

Two transferable lessons. First, a silently-ignored config key is worse than no config at all — the workflow YAML looked hardened, and a reviewer would reasonably have concluded the agent could only echo. This is adjacent to the "annotation is documentation, not a security boundary" class this repo tracks (Semantic Kernel, Composio tool registration, IAM role names in Zapocalypse) — except here the boundary was genuinely intended, and a schema rename disconnected it without telling anyone. Second, fail-open on an unreadable allowlist is the wrong default: for a tool whose whole risk model is "which commands may the model run," a missing allowlist should permit nothing.

Note also that the vendor's own scaffolding shipped both halves of this — the deprecated key and the over-broad IAM binding. A team following Google's documentation exactly ended up with an anonymous-issue-to-Editor path. Compare GitLost (GitHub Agentic Workflows) and "I'll Just Call You" (Google ADK's own triage bot) — the same product family failing the same way, two weeks earlier.

Sourcing note for this update: single primary source. Pillar is a researcher blog this repo weights highly, the writeup is detailed and internally consistent, and Google confirmed and remediated through its VRP — but no independent second source was found this sweep, and with no CVE assigned there is no NVD/GHSA record to cross-check against.

Update — 2026-08-25: the same Black Hat talk names a third tool — OpenAI Codex — with no CVE and a fix that only covers OpenAI's own repo

The "GitHub issue reaches CI secrets" framing this advisory already tracks for Claude Code and Gemini CLI covered three tools in Novee Security's actual Black Hat USA 2026 talk ("If You Run These Automations, You're Exposed Too: Critical Flaws in Anthropic, Google, and OpenAI's Coding Agents," presented by Elad Meged, 2026-08-06), not two. The third, previously untracked in this repo, is OpenAI Codex, and it fails through a distinct mechanism: a multi-pass agent pattern where two Codex runs share one workspace checkout.

Attack chain: (1) an attacker's GitHub issue body is written to the shared workspace as codex-current-issue.json; (2) a prompt injection in that issue diverts Codex's first pass into writing a malicious AGENTS.md file — the project-instructions file Codex automatically reads on its next run; (3) the first pass's output is made to fail schema validation, by design of the injection; (4) that failure triggers a second Codex pass in the same checkout, which loads the attacker-authored AGENTS.md as trusted instructions; (5) the attacker now has standing control over the second pass's actions. Novee's own framing: "The workflow validated the output. The attacker wrote the instructions."

No CVE was assigned — Novee's writeup states plainly that nobody files a CVE for "a just now documented behavior," and OpenAI treated this as a design-pattern disclosure rather than a product vulnerability. OpenAI did patch its own openai/codex repository (splitting the two passes into separate jobs with independent checkouts, and in later iterations removing the shared checkout entirely, plus documenting AGENTS.md as an untrusted input surface) — but per Novee, that fix did not propagate to any external repository running the same two-pass pattern. Treat this the same way this repo already treats "vendor patched ≠ patched": the underlying design flaw (an instruction file written by an earlier, untrusted-input-tainted step being read as authoritative by a later step in the same checkout) is unfixed everywhere except OpenAI's own workflow.

This is the same root shape this repo already tracks as "check-vs-effect scope disagreement" (see the caution notes: Windsurf CVE-2025-62353) and "AI-agent config files are a write-target" (AGENTS.md joins .cursorrules/CLAUDE.md/SKILL.md) — an earlier, attacker-influenced step writes to a file a later, more-trusted step will read as ground truth, and no component in between re-validates that the file's contents are still safe to trust.

Am I affected? If you run any multi-pass Codex automation (or any agent automation generally) where two invocations share a workspace/checkout and an AGENTS.md, CLAUDE.md, or equivalent instruction file persists between passes, and the first pass processes untrusted input (a GitHub issue, PR body, or comment), you have this exposure regardless of which vendor's agent you're running — this is a pattern bug, not a single product's bug.

If you are affected: split multi-pass agent workflows into separate jobs with independent, fresh checkouts (OpenAI's own fix); or, if a shared checkout is unavoidable, diff/re-validate any instruction file (AGENTS.md, CLAUDE.md, .cursorrules) between passes and reject the run if it changed from the version checked out at job start.

Sourcing: Novee Security's own writeup (primary, full attack-chain detail) and The Hacker News (already cited above in this advisory, independently confirms Codex as a third affected tool with the same "shared checkout, JSON validation failure triggers second pass" mechanism and "no CVE assigned" status) — two independent sources.

Sources