Critical Gemini CLI Vulnerability Lets Attackers Execute Code in CI/CD Workflows

Google has patched a critical Gemini CLI vulnerability that could let attackers execute arbitrary code in certain automated development workflows. The issue affects Gemini CLI and the run-gemini-cli GitHub Action when used in headless environments such as GitHub Actions.

The flaw is tracked as CVE-2026-12537 in NVD and as GHSA-wpqr-6v78-jr5g in GitHub’s advisory system. The GitHub security advisory rates the issue critical with a CVSS 3.1 score of 10.0.

The risk centers on CI/CD workflows that process untrusted repository content, such as pull requests or issue data from outside contributors. In affected versions, Gemini CLI could trust workspace configuration in headless mode and load unsafe local files before the sandbox protections took effect.

What CVE-2026-12537 affects

CVE-2026-12537 affects the @google/gemini-cli npm package before version 0.39.1 and the run-gemini-cli GitHub Action before version 0.1.22. Preview users should update to 0.40.0-preview.3 or later.

The NVD entry for CVE-2026-12537 describes the issue as improper neutralization used in an OS command in the container launcher. It says a malicious .gemini/.env file can enable pre-sandbox host-level code execution on headless CI platforms.

OSV also tracks the same issue under the GitHub advisory ID. The OSV vulnerability record describes it as remote code execution through workspace trust and tool allowlisting bypasses.

Component	Affected versions	Patched versions	Main risk
@google/gemini-cli	Before 0.39.1	0.39.1 or later	Unsafe workspace trust in headless mode
@google/gemini-cli preview	Before 0.40.0-preview.3	0.40.0-preview.3 or later	Unsafe configuration loading in automated workflows
google-github-actions/run-gemini-cli	Before 0.1.22	0.1.22 or later	CI/CD execution against untrusted content

Why the vulnerability is critical

The issue received the maximum severity score because exploitation can happen over the network with low attack complexity, no privileges, and no user interaction in vulnerable workflows. The impact can include loss of confidentiality, integrity, and availability.

The Gemini CLI advisory says the impact is limited to workflows using Gemini CLI in headless mode. That still matters because many teams now use AI agents to review pull requests, triage issues, summarize changes, or help automate development tasks.

In practice, a malicious contributor could place crafted Gemini configuration in a repository workspace. If a vulnerable workflow processed that content, the CLI could load it as trusted configuration and trigger code execution on the CI runner.

How the attack path works

The first problem involved folder trust in non-interactive environments. Earlier Gemini CLI versions automatically trusted workspace folders in headless CI mode and loaded configuration files and environment variables from the local .gemini directory.

That behavior created a dangerous gap when a workflow ran against untrusted repository content. A pull request, fork, or issue-driven workflow could place attacker-controlled configuration where the agent expected project settings.

Novee Security, one of the research teams credited in the disclosure, said the flaw could let an unprivileged attacker force malicious content to load as Gemini configuration. The Novee Security analysis said execution could happen on the host before the agent’s sandbox initialized.

The yolo mode allowlist issue

A second issue involved tool allowlisting when Gemini CLI ran in yolo mode. In earlier versions, fine-grained tool allowlists could be ignored when this mode was enabled.

That meant an allowlist intended to permit a narrow shell command could effectively allow a broader set of commands. In workflows that process untrusted content, prompt injection could then become a route to remote code execution.

The Hacker News reported that Google fixed the issue in the affected Gemini CLI and GitHub Action packages. The Hacker News coverage also noted that the impact applies to headless workflows and affected versions below the fixed releases.

Key vulnerability details

Detail	Information
CVE	CVE-2026-12537
GitHub advisory	GHSA-wpqr-6v78-jr5g
Severity	Critical
CVSS	10.0
Primary environment	Headless CI/CD workflows
Attack requirement	Attacker-controlled content in a processed workspace
Known exploitation	No public exploitation listed in NVD

The CVE-2026-12537 record lists CISA SSVC exploitation as none, automatable as yes, and technical impact as total. That combination means defenders should patch quickly even without public exploitation reports.

The OSV advisory lists a CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, which explains why the issue received the maximum 10.0 score.

The vulnerability was reported through Google’s Vulnerability Rewards Program by Elad Meged of Novee Security and Dan Lisichkin of the Pillar Security research team.

Why CI/CD workflows face the highest risk

The vulnerability matters most in workflows that combine three things: untrusted input, Gemini CLI execution, and access to secrets or build privileges. That combination turns a normal automation helper into a potential supply-chain entry point.

GitHub Actions runners often have access to repository tokens, workflow permissions, cloud credentials, package publishing keys, or build artifacts. If attackers reach the runner host, they may be able to steal secrets or alter outputs.

This is why teams should avoid running powerful AI agents on untrusted pull requests without strict boundaries. AI workflow automation needs the same security controls as any other code-executing CI job.

What Google changed in patched versions

The patched Gemini CLI versions require explicit workspace trust in headless mode before local configuration and environment files are processed. This aligns automated behavior with the trust model used in interactive sessions.

The update also changes yolo mode behavior. Gemini CLI 0.39.1 now evaluates fine-grained tool allowlists under yolo mode, which helps CI workflows permit only specific safe commands when handling untrusted inputs.

Google’s Gemini CLI configuration documentation explains that the tool can use project settings, user settings, environment variables, command-line arguments, approval modes, allowed tools, and sandboxing options.

Immediate steps for developers and DevOps teams

Teams should upgrade Gemini CLI and run-gemini-cli immediately, then audit workflows that run Gemini against untrusted content. Updating the package alone may not fix unsafe workflow design if the pipeline still grants excessive permissions.

• Upgrade @google/gemini-cli to 0.39.1 or later.
• Upgrade preview builds to 0.40.0-preview.3 or later.
• Upgrade google-github-actions/run-gemini-cli to 0.1.22 or later.
• Review workflows that run on pull_request, issue_comment, or other untrusted events.
• Use GEMINI_TRUST_WORKSPACE only for trusted repositories and trusted inputs.
• Limit workflow permissions and avoid exposing secrets to untrusted jobs.
• Use strict tool allowlists and avoid broad shell command access.

The Novee report frames the issue as a supply-chain risk because CI/CD agents often run with access to code, secrets, and deployment paths.

How to harden Gemini CLI workflows

Organizations should treat AI agents in CI/CD as privileged automation, not as simple chat tools. Any agent that can read repository files, load configuration, call tools, and run shell commands needs strict boundaries.

For trusted workflows, teams can explicitly set workspace trust after reviewing the repository and event source. For untrusted workflows, teams should isolate runners, avoid secrets, reduce token scopes, and keep shell access narrow.

The Gemini CLI docs state that yolo mode automatically approves all tool calls, while the allowed-tools option can bypass confirmation for selected tools. Those settings require careful review in automated pipelines.

What security teams should monitor

Security teams should review recent CI/CD runs that used affected Gemini CLI or run-gemini-cli versions. Priority should go to workflows triggered by untrusted pull requests, comments, or repository events.

• Unexpected command execution from Gemini CLI jobs.
• Access to secrets during workflows triggered by untrusted contributors.
• Modified .gemini directories in pull requests or forks.
• Outbound network calls from CI jobs that should only review code.
• Unexpected changes to build artifacts, release files, or deployment metadata.
• Workflow logs showing configuration loaded from untrusted workspaces.

The Hacker News article said the affected packages include @google/gemini-cli before 0.39.1, the preview line before 0.40.0-preview.3, and run-gemini-cli before 0.1.22.

Why this vulnerability matters beyond Gemini CLI

The Gemini CLI vulnerability shows a broader risk in AI-assisted development. Coding agents now operate inside build systems, review pipelines, and repository automation, often with access to sensitive credentials and trusted execution contexts.

Traditional CI/CD security already warns against running untrusted code with privileged tokens. AI agents add another layer because they can transform repository text, configuration, and prompts into tool use and command execution.

Organizations using AI in pipelines should review all agentic workflows, not only Gemini CLI. The right model is least privilege, explicit trust, isolated execution, visible logs, and no production secrets in jobs that process untrusted input.

FAQ