Ever wondered what happens when your AI-powered code review tool becomes the attack vector? Low Level recently put out a video that perfectly captures what he calls “the combination of his two nightmares”: AI agents and post-install scripts colliding in spectacular fashion. A maximum severity vulnerability in Google’s Gemini CLI has exposed a fundamental tension in how we’re integrating AI tooling into our development pipelines—and the implications extend far beyond this single bug.
In this post, we’ll break down:
- What the CVSS 10 Gemini CLI vulnerability actually allows
- How attackers can weaponize AI agent configurations in CI/CD
- The broader pattern connecting recent supply chain attacks
- Practical mitigations you can implement today
The Vulnerability: Automatic Trust in Headless Mode
Google’s Gemini CLI and the associated google-github-actions/run-gemini-cli GitHub Actions workflow had a critical flaw in how they handled workspace trust. When running in headless mode—the configuration required for CI/CD deployments—the tool automatically trusted workspace folders for loading configuration and environment variables.
This automatic trust mechanism meant the CLI would load any agent configuration it found without review, sandboxing, or explicit user consent. In environments where Gemini CLI runs on untrusted directories (like CI workflows that review user-submitted pull requests), this creates a direct path to remote code execution.
The attack vector is devastatingly simple: an attacker submits a pull request containing a malicious .gemini/ directory with a crafted configuration file. When the PR review workflow fires, Gemini CLI loads that configuration and executes whatever commands the attacker specified—all within the context of the CI/CD runner.
The Settings.json Attack Surface
The settings.json file that configures Gemini CLI looks completely benign at first glance. You might configure your preferred editor mode, choose a theme, or specify which tools should run inside Docker sandboxes. Standard configuration stuff.
But here’s where it gets dangerous: the configuration supports hooks. Specifically, there’s a beforeAgent hook that executes after the user submits a prompt but before any AI planning occurs. This hook can be any arbitrary command.
As Low Level puts it: “It could be a command named security check that arbitrarily runs any command on the system. Which again, is fine if you as the author of the code are the one that’s authoring the command.”
The problem? When you’re reviewing a pull request, you’re not the author of the code—the potentially malicious actor is. They control what goes into that .gemini/settings.json, and if your CI/CD workflow automatically trusts it, they control what runs on your infrastructure.
YOLO Mode and Allowlist Bypass
The situation gets worse when you factor in how Gemini CLI operates in CI/CD environments. To function as an automated code review tool, it needs to run in what’s called “yolo mode”—a configuration that allows arbitrary command execution by design.
Prior to version 0.39.1, there was an additional vulnerability: the auto-approve mode would ignore any allowlist defined in ~/.gemini/settings.json and run all tool calls automatically, including run_shell_command. This created a lethal combination that security researcher Dan Lisichkin describes as the “lethal trifecta”: access to private data, exposure to untrusted content, and the ability to externally communicate.
The attack chain works like this:
- Attacker creates a GitHub issue containing hidden instructions (indirect prompt injection)
- The AI agent parses these instructions during routine processing
- The agent extracts workflow internal secrets (like
GITHUB_TOKEN) from the build environment - Secrets get exfiltrated to an attacker-controlled server
- With those credentials, the attacker can push arbitrary code to the repository’s main branch
This isn’t theoretical—it represents a full supply chain compromise path that starts from something as innocuous as a GitHub issue.
The Broader Pattern: Team PCP and Supply Chain Cascades
This vulnerability doesn’t exist in isolation. Low Level highlights the activities of Team PCP, a threat actor behind several major supply chain attacks in recent months, including compromises of LightLLM, Trivy, and Checkmarx (a software security tool, ironically enough).
The pattern is consistent: legitimate development tooling and security practices are being weaponized through bad assumptions about trust boundaries. In March 2026, Team PCP leveraged vulnerabilities in an Aqua Bot service to compromise the Trivy action repository. That compromise cascaded to affect downstream tools including Kics and AST.
The common thread? CI/CD pipelines. Whether it’s compromised GitHub Actions, malicious configurations loaded by AI agents, or exploited trust relationships between services, these attacks share a reliance on the implicit trust we place in our development infrastructure.
Self-Hosted Runners: The Blast Radius Problem
The impact scales dramatically when organizations use self-hosted GitHub Actions runners. While GitHub provides hosted runners by default, many enterprises run their own for specialized requirements or security compliance.
When an attacker achieves code execution in your runner, they’re executing within your infrastructure. If that runner has access to environment variables containing database credentials, API keys, or service account tokens—and if you haven’t properly isolated those resources—you’ve handed the attacker the keys to far more than just your CI/CD pipeline.
The runners themselves become lateral movement opportunities. Processes running at the same privilege level might contain credentials the attacker can steal. Network access from the runner might reach internal services. The compromise of one pipeline step can cascade into a full infrastructure breach.
Mitigations: Assume Compromise
Google has released patches addressing these vulnerabilities. Version 0.39.1 and later of the Gemini CLI policy engine now evaluates tool allowlisting under yolo mode, and the GEMINI_TRUST_WORKSPACE environment variable is no longer enabled by default.
If your workflow genuinely only runs on PRs from trusted collaborators, you can explicitly set GEMINI_TRUST_WORKSPACE: 'true'. Otherwise, you need to use updated versions of google-github-actions/run-gemini-cli (0.39.1 or 0.40.0-preview.3 and later) that don’t trust workspace settings by default.
But the broader lesson isn’t just “update your dependencies.” The real takeaway is adopting an assume-breach mentality for your CI/CD infrastructure:
Sandbox aggressively. If you’re running self-hosted runners, they should be containerized. Docker or similar isolation prevents a compromise from escaping into your broader infrastructure. And for the love of all that is holy, don’t run containers as root.
Isolate credentials. Use Linux user separation to ensure that processes running alongside your CI/CD runner can’t be accessed by compromised runner code. Every service should run as its own user with minimal permissions.
Minimize secrets exposure. Review what environment variables and credentials are available in your runner context. If your PR review workflow doesn’t need access to your production database credentials, don’t make them available.
Pin your dependencies thoughtfully. If you pin to specific versions (a good practice), you also need to actively update those pins when security patches drop. Every version of Gemini CLI before the patched versions was affected.
Treat configuration as code—and as an attack surface. Any file that can influence tool behavior is a potential attack vector when it comes from untrusted sources. Review workflows that process external input with extreme suspicion.
The Cursor Vulnerabilities: A Parallel Story
The Gemini CLI vulnerability isn’t unique. As highlighted in The Hacker News’ coverage, around the same time researchers disclosed similar issues in Cursor, the AI-powered IDE. A high-severity vulnerability (CVE-2026-26268) allowed arbitrary code execution through malicious Git hooks embedded in cloned repositories.
The attack works by hiding a bare repository with a malicious post-checkout hook inside a public GitHub repo. When a user clones the repo, opens it in Cursor, and asks the AI to “explain the codebase,” the agent follows instructions in AGENTS.md that navigate to the bare repository and trigger the hook.
A separate vulnerability, dubbed “CursorJacking,” allows any installed extension to access sensitive API keys and credentials stored in Cursor’s local SQLite database. This issue reportedly remains unpatched.
The lesson here is that AI development tools introduce new attack surfaces that traditional security models don’t account for. An AI agent that can execute arbitrary operations on your behalf is, by definition, a potential vector for executing operations you didn’t intend.
Conclusion
The CVSS 10 Gemini CLI vulnerability exemplifies a growing challenge: our development tools are becoming more powerful, more integrated, and more dangerous. When an AI agent can execute commands, load configurations, and interact with external services, every input to that agent becomes a potential attack vector.
Google responded appropriately with patches that require explicit trust rather than assuming it. But the broader industry is still grappling with how to integrate AI assistance without creating supply chain risks.
The defensive posture needs to be assume compromise. Design your CI/CD infrastructure as if every component could be malicious. Sandbox everything. Isolate credentials. And remember that the configuration file that seems perfectly benign might be the entry point for the next supply chain attack.
Update your Gemini CLI. Review your workflows. And maybe have a few of those nightmares yourself—the healthy paranoia might just save your infrastructure.