CRITICAL: Google Gemini CLI Earns CVSS 10 By Trusting Every Folder It Touches

If you have been quietly piping AI agents into your build pipeline because the CI logs make it feel productive, today is the day to slow down and read the changelog. Google shipped a fix on April 24 for a vulnerability in the Gemini CLI that scored a perfect 10.0 on CVSS, and the only reason it is not already a household name is that the GitHub Security Advisory has not been assigned a CVE identifier yet. The advisory lives at GHSA-wpqr-6v78-jr5g, and if you are running @google/gemini-cli below 0.39.1, the 0.40 preview below 0.40.0-preview.3, or the google-github-actions/run-gemini-cli action below 0.1.22, you should stop reading after this sentence and go pin the patched versions before doing anything else.

For everyone still here, the technical story is one of those classics where a well-meaning developer experience choice becomes a remote code execution primitive. Gemini CLI, like most agentic command-line tools, supports an interactive mode for humans and a headless mode for automation. In the interactive case, when you cd into a new project, the tool politely asks whether you trust the workspace before loading any local configuration from a .gemini/ folder. That prompt exists for a very good reason. Anything in .gemini/ can override agent behavior, define environment variables, declare allowed shell commands, and generally tell the model "yes, you may run rm -rf as long as it is in the path." The headless mode, designed for CI/CD pipelines that have no human to click through dialogs, took a shortcut. It auto-trusted whatever workspace it landed in. That meant any repository the runner cloned, any submodule it pulled, any folder a webhook handler decided to inspect was treated as gospel.

The exploit pattern writes itself. An attacker drops a .gemini/settings.json into a public repo, or a forked branch, or a malicious package, and waits for a pipeline to run Gemini against it. The CLI loads the configuration before the sandbox even has a chance to spin up, the agent reads whatever environment variables the file declares, and any command-execution capability the workflow permits becomes the attacker's command-execution capability. Novee Security researcher Elad Meged, who discovered the flaw independently of Pillar Security's Dan Lisichkin, put it bluntly in the public writeup. Code execution on the host running the agent handed an unprivileged outsider whatever secrets, credentials, and source code the workflow could touch, opening the door to token theft, supply-chain pivots, and lateral movement. In a typical GitHub Actions environment that means cloud provider tokens, npm publish credentials, container registry pushes, and read-write access to the repo itself. The kind of access that lets an attacker tag a release nobody asked for.

The second half of the advisory addresses a related but distinct issue. The infamous --yolo flag, which is exactly what it sounds like, was supposed to coexist with a fine-grained tool allowlist. In the affected versions, --yolo simply ignored the allowlist. If you had carefully restricted Gemini to a handful of safe commands and then enabled --yolo because the model kept refusing benign reads, you were one prompt injection away from arbitrary shell execution. The CVSS vector tells the same story across both bugs. Network attack, low complexity, no privileges, no user interaction, scope changed, and complete loss of confidentiality, integrity, and availability. AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. There is no version of that string that lets you sleep on it.

Affected products span a wider blast radius than the version numbers suggest. The google-github-actions/run-gemini-cli action, by default, pulls the latest published Gemini CLI release at runtime. If you adopted the action and did not pin a specific CLI version, you were carrying the vulnerable code into every workflow that referenced it. Any organization that integrated Gemini into automated PR review, automated test triage, automated release notes generation, or any of the agentic CI patterns that have exploded over the past year was exposed by default. The advisory is explicit that the impact is bounded to headless mode, which is small comfort because headless mode is exactly where the high-value secrets live. Your laptop has your password manager. Your CI runner has the production deploy key.

Patching is the easy part. Upgrade @google/gemini-cli to 0.39.1 or 0.40.0-preview.3, depending on which track you are on, and bump google-github-actions/run-gemini-cli to 0.1.22. The harder part is the breaking change Google bundled with the fix. Going forward, headless mode will refuse to load workspace configuration unless you explicitly opt in, either by setting the GEMINI_TRUST_WORKSPACE environment variable to 'true' in workflows where the input is genuinely trusted, or by redesigning the pipeline to keep agent execution well away from any path an outside contributor can influence. Workflows that previously relied on implicit trust will silently start failing or behaving differently, and the --yolo allowlist behavior has changed too, so any pipeline that depended on the old bypass will need its allowlist adjusted before it works again. This is one of those rare cases where reading the release notes before deploying the patch is genuinely required.

Google credits both Meged and Lisichkin for coordinated disclosure. The patch landed on April 24, the researcher writeups went public on April 29, and The Register lit the story up on April 30. As of this writing, no public reporting points to in-the-wild exploitation, but the proof-of-concept work is straightforward enough that anyone watching the advisories now has a roadmap. The mismatch between the severity of the bug and the speed of broad awareness is exactly the kind of window opportunistic attackers love.

Detection is awkward because the legitimate behavior and the malicious behavior look identical at the syscall layer. The agent reads a config file. The agent runs a command. There is no malware signature to match, no anomalous network destination to alert on, just a CI job doing exactly what you told it to do, which happens to include exfiltrating your AWS credentials. The realistic detection strategy hinges on workflow-level controls. Audit your GitHub Actions usage for any reference to run-gemini-cli or direct npm install of @google/gemini-cli, alert on workflows that execute against untrusted ref contexts such as pull_request_target with code from forks, and review your existing GEMINI_TRUST_WORKSPACE settings to confirm they actually reflect the trust posture of the input. If you have a SIEM ingesting GitHub audit logs, hunt for workflow runs that touched .gemini/ directories from external contributors over the past several months. The vulnerability has existed long enough that prior exploitation, while currently unconfirmed, is not ruled out, and the cost of looking is low.

There is a broader architectural point worth sitting with. The whole reason this bug exists is that agentic tools blur the line between code and configuration. A traditional CLI tool reads a config file and changes its behavior in narrow, predictable ways. An agentic tool reads a config file that can grant it the ability to execute arbitrary shell commands on your behalf, which means the config file is effectively code, which means it needs to be treated with the same provenance rigor as any other executable in your pipeline. That is not how most teams are deploying these tools. They are being added the same way developers added linters and formatters a decade ago, with the assumption that the worst case is a noisy log line. The Gemini CLI advisory should be the moment the industry stops assuming that.

If you are running any LLM-backed coding agent in CI, you are running an interpreter that can be reprogrammed by anyone who controls a file in the repo, and you need to architect accordingly. The same caution applies to Cursor, which the same Hacker News writeup flagged for a CVSS 8.1 RCE via malicious git hooks tracked as CVE-2026-26268, and to Claude Code, Aider, and every other entrant in this category. The class of vulnerability, not the specific vendor, is what matters. Expect more of these advisories to land throughout 2026 as researchers turn their attention to the agent ecosystem, and expect a fair number to ship without CVE numbers attached, which makes vendor advisory monitoring more important than relying on the NVD feed alone.

For MSPs, this is the conversation to have with every developer-heavy client this week. The pitch is straightforward. Most engineering organizations have rolled out one or more AI coding agents over the past twelve months without subjecting them to the same supply-chain review they would apply to any other dependency, and the Gemini CLI advisory is the proof that those tools can pop a CI runner just like a malicious npm package can. There is a real services bundle here, covering an AI tool inventory across the client estate, a CI/CD trust boundary review, a hardened workflow template that pins agent versions and explicitly scopes trust, and ongoing monitoring of the agent ecosystem advisories that, as this case demonstrates, are now landing without CVE numbers attached. Clients who have been told "we use AI now" by their dev teams without anyone in security being involved will see the value immediately.