CVSS 10 in Your CI Pipeline: The `gemini-cli` Supply Chain RCE
Just caught the update on The Hacker News regarding the @google/gemini-cli package. We're looking at a CVSS 10.0 remote code execution (RCE) flaw that impacts not just the npm package but the associated GitHub Actions workflow google-github-actions/run-gemini-cli.
The core issue is an unsafe configuration loading mechanism. The vulnerability allows an unprivileged external attacker to force their own malicious content to load as Gemini configuration. In a CI/CD context, this is catastrophic—it essentially hands the keys to your build runner to an attacker. If the workflow has access to secrets or deployment tokens, you're looking at a complete pipeline compromise.
If you are utilizing this package, immediate patching is non-negotiable. You should verify the installed versions locally and in your CI logs. You can check your lockfile for the affected package using:
grep -A 5 'google/gemini-cli' package-lock.
For the GitHub Actions users, ensure you are pinning to a specific commit SHA or a patched release tag rather than a mutable version tag like v1.
This highlights a growing trend with AI SDKs entering the supply chain. How is everyone else handling the vetting process for these AI-centric dependencies? Are you treating them with the same scrutiny as standard crypto or auth libraries?
This is exactly why we moved to pinning every dependency by commit SHA in our GitHub Actions, not just the AI ones. The mutable tag risk is too high. We ran a quick scan using npm audit and found we were technically 'safe' on the version, but the workflow definition was pointing to a vulnerable tag.
For detection, we're adding a KQL rule to our Sentinel ingestion to look for gemini-cli spawning unexpected child shells:
ProcessCreateEvents
| where FileName has "gemini-cli"
| where ProcessCommandLine contains "--config" and ProcessCommandLine contains "http"
Stay safe out there.
I'm less worried about the npm package and more worried about the GitHub Action aspect. A lot of junior devs just copy-paste the 'usage' block from the README which defaults to @main or @v1. If the maintainer gets compromised or pushes a bad config parser, everyone downstream gets hit.
We are implementing a policy where no action can run unless it is verified against our internal registry. It's a pain to manage, but after seeing CVSS 10s in build tools, I can't justify the risk anymore.
Just finished patching our fleet. The scary part is how silent this exploitation could be. Since it loads a malicious config, the RCE might look like 'legitimate' tool behavior unless you are closely monitoring egress traffic from the runner.
If you can't patch immediately, consider blocking external config loading at the network layer. The vulnerability requires fetching the malicious content, so if your runners have no internet access (except to specific registries) and don't accept user-supplied URLs, you reduce the attack surface significantly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access