GHSA-wpqr-6v78-jr5g — google-github-actions/run…
CRITICALGHSA-wpqr-6v78-jr5g is a critical-severity (CVSS 10) Improper Input Validation vulnerability in google-github-actions/run-gemini-cli. A fix is available for google-github-actions/run-gemini-cli — see the affected versions and patch details below.
Gemini CLI: Remote Code Execution via workspace trust and tool allowlisting bypasses
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wpqr-6v78-jr5g.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-wpqr-6v78-jr5g plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@google/gemini-clinpmDescription
Summary
Gemini CLI (@google/gemini-cli) and the run-gemini-cli GitHub Action are being updated to harden workspace trust and tool allowlisting, in particular when used in untrusted environments like GitHub Actions. This update introduces a breaking change to how non-interactive (headless) environments handle folder trust, which may impact existing CI/CD workflows under specific conditions.
Details
Folder Trust in Headless Mode
In previous versions, Gemini CLI running in CI environments (headless mode) automatically trusted workspace folders for the purpose of loading configuration and environment variables. This is potentially risky in situations where Gemini CLI runs on untrusted folders in headless mode (e.g. CI workflows that review user-submitted pull requests). If used with untrusted directory contents, this could lead to remote code execution via malicious environment variables in the local .gemini/ directory.
To ensure consistency and user control, the latest update aligns headless mode behavior with interactive mode, requiring folders to be explicitly trusted before configuration files (such as .env) are processed.
As a result of this change, 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.
Tool Allowlisting under --yolo
In previous versions, when Gemini CLI was configured to run in --yolo mode, it would ignore any fine grained tool allowlist in ~/.gemini/settings.json (e.g. run_shell_command(echo) would allow any command). This is potentially risky in situations where Gemini CLI runs on untrusted inputs with --yolo (e.g. CI workflows that triage user-submitted GitHub issues where we recommend a strict allowlist). If used with untrusted content and a tool allowlist that permits run_shell_command, this could lead to remote code execution via prompt injection.
In version 0.39.1, the Gemini CLI policy engine now evaluates tool allowlisting under --yolo mode, which is useful for CI workflows that allowlist a few safe commands to run when processing untrusted inputs. As a result, some workflows that previously depended on this behavior may fail silently unless tool allowlists are modified to fit the task.
Impact
This impact is limited to workflows using Gemini CLI in headless mode. Any use of Gemini CLI in headless mode without folder trust will require manual review to correctly configure folder trust. This affects all Gemini CLI GitHub Actions. Users must review their workflows, and take one of two approaches:
1. If the workflow runs on trusted inputs (e.g. reviewing PRs from trusted collaborators), set GEMINI_TRUST_WORKSPACE: 'true' in your workflow.
2. If the workflow runs on untrusted inputs, review our guidance in google-github-actions/run-gemini-cli to harden your workflow against malicious content, and set the environment variable.
Patches
The folder trust and tool allowlisting mitigations are available in @google/gemini-cli version 0.39.1 and 0.40.0-preview.3. By default, the run-gemini-cli GitHub Action will receive and run the latest version of gemini-cli. However, if your workflow specifies a version of gemini-cli by setting the gemini_cli_version, you are encouraged to upgrade to one of the patched versions and audit the workflow settings that use Gemini CLI.
Credits
Gemini thanks the following security researchers for reporting this issue through the Vulnerability Rewards Program (g.co/vulnz):
- Elad Meged, Novee Security
- Dan Lisichkin, Pillar Security research team
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦GitHub Actions | google-github-actions/run-gemini-cli | all versions | 0.1.22 |
| 📦npm | @google/gemini-cli | all versions | 0.39.1npm install @google/gemini-cli@0.39.1 |
| 📦npm | @google/gemini-cli | ≥ 0.40.0-preview.2&&< 0.40.0-preview.3 | 0.40.0-preview.3npm install @google/gemini-cli@0.40.0-preview.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for google-github-actions/run-gemini-cli, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update google-github-actions/run-gemini-cli to 0.1.22 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wpqr-6v78-jr5g is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-wpqr-6v78-jr5g can be triaged on real exposure rather than presence alone.
Tailored to GHSA-wpqr-6v78-jr5g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wpqr-6v78-jr5g in your dependencies?
O3 Security finds GHSA-wpqr-6v78-jr5g across GitHub Actions, npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.