How the bug worked: headless mode and over‑permissive workspace trust
Google's advisory on GitHub describes a critical remote code execution vulnerability, scored CVSS 10.0, that arose from how Gemini CLI handled workspace folder trust in headless mode. Headless mode — frequently used in CI/CD environments and by AI agents — automatically assumed any workspace folder it ran in was trusted for the purpose of loading configuration files and environment variables. That meant attacker‑controlled files in a workspace could be treated as trusted configuration and executed before any sandboxing was applied.
In contrast, Gemini CLI's interactive mode required users to explicitly mark a folder as trusted before workspace configuration files would be loaded. The update brings headless mode into parity with interactive mode: headless mode no longer assumes automatic trust.
Which versions fix it and how the GitHub Action complicates rollout
Google shipped mitigations in Gemini CLI versions 0.39.1 and 0.40.0‑preview.3. The run‑gemini‑cli GitHub Action, however, defaults to the newest Gemini CLI release unless users explicitly pin a version. That behavior means some users were patched automatically while others may find their workflows broken — or still vulnerable if they are pinned to older releases.
Google warned that "GitHub Actions and other automated pipelines that rely on the previous automatic trust behavior will fail to load workspace‑specific settings until they are updated to use explicit trust mechanisms." In short: unpinned actions may now behave more securely by default, but that same change can produce immediate, functional regressions in CI/CD workflows that depended on prior implicit trust.
--yolo mode: a separate backward‑compatibility bite
Workflows that relied on the CLI's --yolo mode should also expect changes. In earlier versions, --yolo bypassed fine‑grained tool allowlists and automatically approved agent actions without prompting. Google notes that "In previous versions, when Gemini CLI was configured to run in --yolo mode, it would ignore any fine grained tool allowlist." Starting with 0.39.1, the policy engine evaluates tool allowlisting even under --yolo. As Google put it, "some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task."
What researchers found and the scale of impact
Two research teams were credited with the discovery: Novee (Elad Meged) and Pillar Security's Dan Lisichkin. Meged says Google is in the process of assigning a CVE and that Novee received a bug bounty, though the company declined to disclose the amount. Novee's testing returned consistent results: code execution on the host running the agent allowed "an unprivileged outsider access to whatever secrets, credentials, and source code the workflow could reach," the team reported. The consequences named were concrete — token theft, supply‑chain pivots, and lateral movement into downstream systems.
Meged emphasized to The Register that the problem was an "infrastructure‑level issue, where attacker‑controlled content was silently accepted as trusted configuration and executed before any sandbox was initialized."
What this means for DevOps, security teams, and CI/CD administrators
- DevOps and CI/CD administrators: Review any workflows that invoke Gemini CLI or the run‑gemini‑cli GitHub Action. If you rely on the action without pinning a version, expect that your pipeline may have been updated to a safer CLI release automatically — and that behavior could break loading of workspace‑specific settings. Pin versions if you need controlled rollout, but also plan to update pinned workflows to accommodate the fixed behavior.
- Security and secrets teams: Treat any environment that allows headless Gemini CLI access to untrusted directories as potentially compromised until you confirm explicit trust boundaries. The researchers found host code execution could expose secrets and credentials accessible to the workflow.
- Teams using AI agents: Recognize that placing agents in sensitive environments carries infrastructure‑level risks unrelated to model behavior. As the source concluded, "take action as Google suggests, or avoid putting AI agents in sensitive environments until the risks are fully understood."
The patch was necessary and decisive — it closes a straightforward path from untrusted workspace files to remote code execution. But the fix also underscores a familiar operational tension: tightening defaults improves security but can break automation that depended on the old defaults. For organizations running Gemini CLI in pipelines, the next steps are concrete and urgent: inventory where the CLI and the run‑gemini‑cli Action are used, decide whether to pin versions or migrate to the new trust model, and adjust tool allowlists if workflows formerly relied on --yolo behavior. Google says it is assigning a CVE for the issue; in the meantime, the advisory and the researchers' writeups are the record to follow.
Original story: https://go.theregister.com/feed/www.theregister.com/2026/04/30/googles_fix_for_critical_gemini/
