Critical Vulnerability in Gemini CLI and GitHub Actions exposes the CI supply chain to remote code execution

Google corrected critical vulnerability in Gemini CLI (package npm @ google / gemini-cli) and in the workflow of GitHub Actions google-github-actions / run-gemini-cli that allowed to run arbitrary commands in the host system when the tool was used in headless mode within CI. The root of the problem was an implicit trust in the work folder: in affected versions the CLI loaded settings and environment variables from .gemini / without validation when running in automated environments, which opened the door to which malicious content planted by an attacker was treated as legitimate configuration and detonated remote code execution.

The defect, qualified with maximum severity (CVSS 10.0) by external researchers, exemplifies how a shortcut of usability in automated pipelines becomes a supply chain attack vector: pull requests analysis, forks or third party content can become traps if a tool assumes that the workspace is reliable. Google mitigated the risk by now forcing the folders to be explicitly marked as reliable before reading configuration files and by proposing environment variables and specific settings for workflows, as well as hardening the allowlist checks when the CLI is run with --yolo.

If you use Gemini CLI in GitHub Actions, the immediate action is to update to corrected versions: install @ google / gemini-cli in versions equal to or greater than those that correct the failure (the vulnerable versions are those indicated by the supplier) and updates google-github-actions / run-gemini-cli to version 0.1.22 or later. Check the repository page to get the releases and the configuration guide: google-github-actions / run-gemini-cli and package npm @ google / gemini-cli en npm.

It is not enough to update: your workflows. If your flow processes only entrances of trusted collaborators you can choose to establish GEMINI _ TRUST _ WORKSPACE: 'true' in the Job environment, but do not do so if you accept contributions from third parties or forks. For unreliable inputs, follow the official hardening guide and treat the workspace as a host: mount ephemeral runners, limit Action permissions with the minimum necessary, disable unnecessary access to secrets and use strict allowlist rules for any functionality that runs commands or processes.

In addition, Google changed the behavior of --yolo (self-approval mode) so that the toollist policy is also evaluated in that mode; that prevents calls to dangerous functions such as run _ shell _ command from running without restrictions. However, the change can cause silent failures in previous workflows, so it is appropriate to review and adjust the allowlists to maintain the required functionality without sacrificing security.

The case of Gemini should be read in conjunction with other recent vulnerabilities in IA-driven tools. Researchers also described an IDE Cursor vector that allowed arbitrary execution through malicious prompt injection techniques and Git hooks within "embedded" (.git) repositories, in addition to a access control failure that allowed local extensions to read credentials stored in SQLite bases. These incidents reinforce a pattern: self-employed agents that perform Git operations or systems that grant extensions privileges can convert legitimate features into attack vectors when combined with malicious repositories or packages.

What to deal with these threats: first, apply patches immediately and subscribe to safety notices of the projects you use. Second, it reduces the attack surface in CI: ephemeral exectors, job separation, manual review of Forks PRs before running workflows that process the content and automated scanning of incoming artifacts. GitHub maintains useful recommendations on action hardening that should be followed: Security harassment for GitHub Actions.

For local development tools like Cursor, the minimum practice is not to open unknown repositories in environments with agents that act automatically, avoid installing unreliable source extensions and limit the access of extensions to the file system. If you already work with local secrets or API keys, you break exposed credentials and use secret and service account managers with limited privileges for CI instead of personal tokens.

Finally, it adopts in-depth defenses: it integrates static analysis and unit scanning into your pipeline, enables security policies that inspect configuration files (including dotfiles such as .git and .gemini), and establishes human approval procedures when an agent is going to run system changes. The convenience of IA agents and automated tools should not replace basic isolation and review controls; defensive security remains the best protection against hidden explosives in the supply chain.