Gemini CLI RCE hits CI/CD pipelines

AI coding agents are starting to live inside CI/CD pipelines — and that means their mistakes become infrastructure mistakes. That is the real story behind the Gemini CLI bug Google patched in late April. A tool meant to read code, review pull requests, and automate developer work could, in the wrong setup, end up executing attacker-controlled commands on the build runner itself. The scary part is not just “RCE in a dev tool.” It is where the tool was running — inside systems that often hold deploy keys, cloud credentials, and signing secrets. (docs.cloud.google.com) ### What is Gemini CLI doing in a pipeline? Gemini CLI is Google’s terminal-based AI agent. Teams use it locally, but they also wire it into GitHub Actions and other automated jobs to review pull requests, triage issues, write fixes, or run security checks. In other words, it is not just a chatbot in a shell — it is software that can inspect a repo and call tools while a workflow is running. (docs.c([docs.cloud.google.com)ere did the bug actually live? The first problem was workspace trust in headless mode. Older Gemini CLI versions would automatically trust the current workspace folder in CI, then load configuration and environment data from that folder. If the workspace contents came from an untrusted pull request or other attacker-controlled input, the tool could end up loading malicious settings from the rep(docs.cloud.google.com)eed explicit trust before those config files get processed. (github.com) ### Why is “headless trust” such a big deal? Because CI runners are supposed to be skeptical by default. A pull request from the internet is basically a stranger handing your build system a folder and saying, “please run this.” Gemini CLI blurred that line by treating the workspace as trusted in non-interactive runs. That let an attacker smuggle instructions in through local Gemini config and get code execution before the ag(github.com)d it as pre-sandbox host execution — which is about as bad as it sounds. (novee.security) ### Was there only one bug? No — there was also a second hardening change around `--yolo` mode. In older versions, Gemini CLI could ignore fine-grained tool allowlists under `--yolo`, which meant a supposedly narrow permission like `run_shell_command(echo)` could effectively turn into permission to run arbitrary shell commands. In CI jobs that process untrusted issues or (novee.security)s are actually enforced in `--yolo` mode. (github.com) ### Which versions were affected? GitHub’s advisory lists `@google/gemini-cli` versions below 0.39.1, plus preview builds up to 0.40.0-preview.2, as affected. The `google-github-actions/run-gemini-cli` action was affected below 0.1.22. Google credits Elad Meged of Novee Security and Dan Lisichkin of Pillar Security for reporting the issue. (github.com) ### Why does this t(github.com)concentrates. If an attacker gets code execution there, they may not just steal one secret. They can tamper with artifacts, poison dependencies, pivot into cloud systems, or alter what gets shipped downstream. The bug was limited to headless Gemini CLI workflows, but those are exactly the places where automation has real privileges. That is t(github.com) the dangerous part is the plumbing around it. (github.com) ### What should teams do right now? Upgrade first. Then audit every workflow that runs Gemini CLI against untrusted pull requests, issues, or repo contents. Google warns the fix is breaking by design — some jobs that relied on automatic workspace trust will stop loading local settings until trust is configured explicitly. Teams should also review any `--yolo` usage, tighten tool allowlists, rotate secrets that may have been exposed, and isolate runners that handle public inputs. (github.com) ### Bottom line This bug is a preview of a broader problem. AI agents are getting dropped into build systems faster than teams are redesigning trust boundaries around them. Gemini CLI’s patch closes one nasty hole, but the lesson is bigger — if an agent can read untrusted content and touch real tools in CI, then the agent is part of your attack surface, not just your developer experience. (docs.cloud.google.com)