Gemini CLI's CVSS 10.0 Bug and AI Agent Security

There's a particular flavor of security nightmare that lives at the intersection of "this tool is genuinely useful" and "this tool can absolutely be weaponized." A recently patched vulnerability in Gemini CLI—rated CVSS 10.0, the maximum possible severity score—lands squarely in that territory. And the Low Level YouTube channel just published a breakdown of exactly how the exploit chain worked, why it's part of a bigger pattern, and what any team running AI-assisted code review in CI/CD should probably be doing differently.

Let's get into it.

The Setup: AI Code Review Is Actually Good (Stay With Me)

Before diving into the attack surface, it's worth acknowledging the legitimate use case here, because the vulnerability only makes sense in that context.

AI-assisted PR review—where a tool like Gemini CLI automatically reads a pull request and summarizes changes, flags potential issues, or adds review context—is a real productivity win for engineering teams. It offloads cognitive overhead from reviewers, catches obvious problems early, and can help teams move faster without sacrificing code quality. This isn't hype; teams are genuinely deploying this in production.

The Gemini CLI integration with GitHub Actions is one concrete implementation of this. You configure a workflow, a PR comes in, Gemini reviews it. Normal stuff. Except for one architectural detail that turns this from "useful automation" into "terrifying attack vector" if you're not careful about it.

The --yolo Flag Is Called --yolo For a Reason

To run Gemini CLI in a headless, automated CI/CD context—where there's no human in the loop to approve each action—the tool has to operate in what's literally called "yolo mode." As the Low Level creator explains: "Yolo mode is literally the mode that allows you to run arbitrary commands on the system, which again is by design when you're doing Gemini CLI in CI/CD. It has to run this way so that the CLI can run arbitrary tooling."

That's not a bug, it's an architectural requirement. A tool doing automated code review needs to be able to execute commands. The problem emerges one layer up, in how that tool is configured.

Gemini CLI uses a settings.json file to configure its behavior—which editor mode to use, which tools to run, how to sandbox operations. Totally normal config file stuff. But buried in that config is a before_agent hook: a command that runs after a user submits a prompt but before the agent begins planning or executing anything. It's designed for legitimate pre-flight checks. And in a world where you control your own settings.json, it's fine.

Here's the problem: when someone submits a pull request, they control the code in that PR—including any settings.json they decide to include.

So the attack chain looked like this: attacker opens a PR → PR triggers the Gemini review workflow → workflow runs Gemini CLI with --yolo → Gemini reads the attacker's settings.json → before_agent hook fires → arbitrary command executes inside the CI/CD runner with the organization's credentials and environment variables in scope.

Game over. API keys, database credentials, tokens—anything sitting in that runner's environment is now potentially readable by whoever crafted that settings.json.

This Isn't an Isolated Incident

The Gemini CLI CVE is fresh and now patched, but the Low Level breakdown situates it inside a pattern that's been accelerating for months: supply chain attacks targeting CI/CD infrastructure, often orchestrated by a threat actor known as Team PCP.

The casualty list is notable. LightLLM. Trivy. Checkmarx. Telniks. Each of these compromises traces back, in some way, to a CI/CD pipeline being treated as inherently trustworthy when it shouldn't have been. The specific mechanics vary, but the meta-pattern holds.

In March, Team PCP leveraged a vulnerability in Aqua's Bot service to compromise the Trivy action repository. The Trivy compromise then cascaded into Kics and AST via vulnerable GitHub Actions. Separately, the Accurics compromise happened because Accurics used the Checkmarx tool internally—so compromising one tool created a downstream blast radius into a second organization.

The Low Level creator is careful not to draw a direct line between the Gemini CLI bug and Team PCP: "I'm not saying that Team PCP exploited a vulnerability in Gemini CLI. That's not what I'm saying at all. What I am saying though is this reliance on CI/CD, which likely now includes AI tooling with settings files that are not properly sanitized, is a large-scale pattern that we're seeing."

That distinction matters. The point isn't that Gemini CLI caused the supply chain attacks—it's that the attack surface that enabled those attacks and the attack surface that the Gemini CVE exposed are structurally similar. The same bad assumption—that code running in your CI/CD runner is trustworthy—underlies both.

Self-Hosted Runners Make This Worse

GitHub-hosted runners have some natural blast-radius containment because they're ephemeral and relatively isolated. But many large organizations run self-hosted runners on their own infrastructure, often because they need specific hardware, specific software environments, or they're operating in regulated environments that prohibit cloud execution.

Self-hosted runners are common, legitimate, and can be configured securely. But if your runner has access to sensitive environment variables—database credentials, production API keys, internal service tokens—and you haven't thought carefully about process isolation, then arbitrary code execution in that runner context is genuinely catastrophic.

The Low Level breakdown emphasizes the privilege isolation problem specifically: if multiple processes run at the same user privilege level on that runner, a compromised workflow can potentially read environment variables set by other processes, not just its own. Linux user separation (running each process as its own system user with minimal permissions) is the recommended mitigation here. Along with Docker containerization—though as noted, running Docker containers as root creates its own set of problems that deserve their own conversation.

What Google's Patch Actually Does

Google's mitigation centers on trust boundaries that weren't enforced before. The new --gemini-trust-workspace flag lets teams explicitly opt into trusting workspace configuration files—but it's now off by default, meaning a malicious settings.json from a PR won't automatically execute hooks.

The patched versions are 0.1.9 and 0.2.0 (for teams tracking the 400-preview-3 branch). Critically, if your workflow pins to a specific older Gemini CLI version—a totally normal and generally good practice for reproducibility—you're still vulnerable until you update that pin. Every version before the patched releases carried this exposure.

"If your workspace genuinely does run only on PRs from trusted collaborators, you can turn on Gemini Trust Workspace and it's all good," the video explains. The flag exists as an escape hatch for closed-source or fully internal repos where all contributors are vetted. For any repo that accepts external PRs—open source projects, repos with external contractors, anything with public-facing contribution workflows—the default non-trust setting is the appropriate posture.

The Harder Question

The pragmatic mitigation list is real and worth following: update your Gemini CLI pin, review your runner's credential exposure, implement Linux user separation, containerize with appropriate non-root policies. This is good hygiene.

But there's a more uncomfortable question lurking in all of this. The Gemini CLI use case—AI agents reviewing untrusted, externally-submitted code—is structurally challenging from a security standpoint in ways that a one-time patch doesn't fully resolve. Every time you add an AI agent to a CI/CD workflow that processes external input, you're expanding the attack surface. The agent has to do something with that input, and "doing something" in a headless automated context almost always means having some level of execution capability.

Teams adopting AI-assisted development tooling are moving fast, and the security mental models haven't necessarily caught up. The assumption that a config file is benign because config files are usually benign is exactly the kind of implicit trust that supply chain attackers have learned to exploit.

Patching the specific CVE is necessary. But the real question is whether the security review process for "what can an attacker do by submitting a PR" is happening rigorously before AI tooling gets wired into CI/CD—or only after a 10.0 CVE shows up and turns the nightmare literal.

---

By Yuki Okonkwo, AI & Machine Learning Correspondent