Gemini CLI headless CI workspace trust flaw: a .gemini/.env file in an outside PR can run commands on the host before the sandbox starts

Who is affected

Sources describe the preview line differently. The CVE record says only ”< 0.39.1”, NVD also lists 0.40.0-preview.2, and the GitHub repository advisory says ”< 0.40.0-preview.3”.

Google’s advisory says the change “affects all” Gemini CLI GitHub Actions. PlainCVE reads this as referring to a behaviour change every user will notice. Actual exploitation still requires the workflow to process untrusted content. That is our interpretation, not a statement from Google.

How it works

Gemini CLI is Google’s AI coding assistant. It reads and writes code from the terminal, and through the run-gemini-cli Action it can run inside GitHub CI, the system that builds and tests code automatically whenever it changes. A common use is reviewing PRs automatically.

A project can ship its own settings in a .gemini/ folder, including a .env file. A .env file holds environment variables, the settings a program reads when it starts. Because those settings come from the code itself, Gemini CLI has “folder trust”: in interactive use it asks whether you trust the folder, and if you don’t, it ignores those settings.

The problem was that headless mode (CI, where nobody is there to click confirm) treated the workspace as trusted automatically. So a .gemini/.env in an outside contributor’s PR got loaded. According to the CVE record, those values reached the “container launcher”, the part that starts the sandbox. The launcher runs on the host before the sandbox starts, so the sandbox couldn’t protect anything. The result is that an attacker could run commands on the build machine. Novee says this exposes the secrets, credentials and source code the workflow can reach, which opens the door to token theft and supply-chain attacks.

Put simply, trust was decided by run mode, not by where the content came from. Google has not said which variable is involved or how the launcher used it, and this page doesn’t guess.

The flawed approach (conceptual illustration, not the original source code):

if headless_mode:
    trusted = True            # CI: just assume the folder is trusted
if trusted:
    load_env(workspace / ".gemini/.env")
launch_container()            # runs on the host before the sandbox, already influenced by .env

The fixed approach:

trusted = is_explicitly_trusted(workspace)   # only if the user explicitly configured trust
if not trusted:
    if headless_mode:
        raise FatalUntrustedWorkspaceError   # stop the run
    # skip .env, workspace settings, MCP servers, etc.
else:
    load_env(workspace / ".gemini/.env")
launch_container()

A second issue in the same advisory (not part of this CVE): Google’s advisory GHSA-wpqr-6v78-jr5g also describes --yolo (auto-approve) mode ignoring the tool allowlist in ~/.gemini/settings.json, which could let prompt injection lead to remote code execution. Pillar Security reported most of that work. The CVE description covers only the .env / container launcher problem, and so does this page. Some secondary sources, including Novee’s vulnerability page and the GitHub Advisory Database summary, describe the two together, so keep that in mind when reading them.

Timeline

The date of Novee’s report is unknown.

Further reading

• Scoring differences: NVD’s CVSS 3.1 score is 7.8 (local attack, user interaction required). Google’s (CNA) CVSS 4.0 score is 10.0, and the GHSA’s CVSS 3.1 score is also 10.0 (network-reachable, no interaction). The gap comes from judging the “outside PR triggers CI” scenario differently. This page’s severity field uses the NVD score.
• CWE mismatch: the CNA tags CWE-20 (improper input validation) and NVD tags CWE-78 (OS command injection). The CVE description’s own wording is closer to CWE-78. The GHSA lists CWE-20, 77, 78 and 200, covering both issues.
• CVE mapping: the GHSA page still shows “No known CVE”, yet the CVE record’s only reference is that GHSA.
• Credits: the GHSA credits Elad Meged (Novee Security) and Dan Lisichkin (Pillar Security). The CVE record credits Elad Meged and Devansh Batham. Devansh Batham’s link to this CVE could not be confirmed.
• Exploitation: no source reports exploitation in the wild. The record we were given says this CVE is not in CISA KEV, but CISA’s site could not be reached during research to confirm this independently.
• No official indicators of compromise were published. The detection and secret-rotation suggestions on this page are PlainCVE’s own inferences.