Security researchers at AIR Security disclosed Plugin4Shell — a zero-click remote code execution vulnerability that breaks the SHA-pin verification mechanism meant to guarantee a plugin repository serves exactly the code a developer approved. It hits four major AI coding agents: Claude Code, OpenAI Codex, GitHub Copilot, and Google Gemini CLI. Anthropic and OpenAI have patched. GitHub Copilot hasn't. And Google's response to its own exposure wasn't a patch at all — it deprecated Gemini CLI, leaving every existing install permanently vulnerable.
TL;DR
| Question | Answer |
|---|---|
| What is it? | A zero-click RCE that breaks SHA-pin plugin-verification integrity |
| Who disclosed it? | AIR Security |
| Which tools are affected? | Claude Code, OpenAI Codex, GitHub Copilot, Google Gemini CLI |
| Fixed? | Anthropic and OpenAI have patched |
| Not fixed? | GitHub Copilot remains unpatched |
| Google's response | Deprecated Gemini CLI instead of patching — existing installs stay exposed |
| Impact if exploited | Attacker-controlled code runs with the developer's full local/cloud credentials |
How SHA-pin verification is supposed to work — and how it broke
SHA-pinning is a standard supply-chain security practice: a developer pins a dependency (in this case, an AI coding agent plugin) to a specific cryptographic hash of its code, so that even if the plugin's repository is later modified, the developer's tooling should refuse to run anything that doesn't match the originally pinned hash. It's meant to be a hard guarantee — the whole point is that it shouldn't matter whether you trust the plugin repository's owner indefinitely, because the pin itself is the check.
Plugin4Shell breaks exactly that guarantee. AIR Security's disclosure describes a flaw that lets a malicious or compromised plugin-repository owner serve different code than what was originally pinned, while the affected coding agent's verification step fails to catch the substitution. Because the attack requires no click or additional approval from the developer beyond having pinned the plugin in the first place, it's classified as zero-click — the exploit executes as soon as the developer's coding agent pulls and runs the substituted code, with no additional user interaction as the trigger point.
Four major agents, three very different responses
What makes this incident worth tracking closely is how differently the four affected vendors responded. Anthropic and OpenAI both patched their respective tools — Claude Code and Codex — closing the SHA-pin bypass in their own verification pipelines. GitHub Copilot remains unpatched as of this writing, meaning developers using Copilot with pinned plugin dependencies are still exposed to the same substitution attack AIR Security disclosed.
Google's response is the most consequential for existing users: rather than patching the underlying flaw in Gemini CLI, Google deprecated the tool entirely. That means any developer with an existing Gemini CLI installation is now running a tool that will never receive a fix for this specific vulnerability — the only real mitigation path for those users is migrating off Gemini CLI altogether, not waiting for an update that isn't coming.
Why "first AI supply-chain vulnerability" framing matters
Individual security bugs in AI coding tools aren't new, but Plugin4Shell is notable as one of the first widely disclosed vulnerabilities to hit the supply-chain trust layer — the plugin/dependency verification mechanism itself — across multiple major AI coding agents through essentially the same underlying flaw class, rather than being a bug isolated to one vendor's implementation. That's a meaningfully different risk category than a single-product bug: it suggests the SHA-pin verification pattern as commonly implemented across these tools shared a similar weakness, which is exactly the kind of systemic, cross-vendor finding that security researchers and AI tooling vendors alike should be paying closer attention to as agentic coding tools become standard developer infrastructure.
Why "deprecate instead of patch" is a genuinely different kind of response
Google's decision to deprecate Gemini CLI rather than patch the underlying SHA-pin verification flaw deserves scrutiny as its own distinct category of vendor response, separate from either "patched quickly" or "hasn't patched yet." Deprecation solves the problem for Google going forward — no new users will adopt a tool the company has stopped supporting — but it does essentially nothing for anyone who already has Gemini CLI installed and integrated into their existing workflows and CI pipelines at the moment of deprecation. Those existing installs don't automatically stop running, and nothing about deprecation itself removes the vulnerable code from a developer's machine; it just means no fix is coming for it. That creates a meaningfully worse outcome for existing users than either of the other two vendor responses in this incident: Anthropic and OpenAI's patched users get an actual fix, and even GitHub Copilot's unpatched-but-still-supported users have a reasonable expectation a fix is still coming. Gemini CLI's existing installed base is left with neither.
The pattern this fits into: plugin ecosystems as the new attack surface
Plugin4Shell is also worth reading as part of a broader, recognizable shift in where AI-tooling security risk is concentrating. As coding agents have matured from single-model chat interfaces into extensible platforms with plugin and extension ecosystems — closely mirroring how browsers, IDEs, and package managers evolved before them — the plugin and dependency-verification layer has become exactly the kind of high-leverage attack surface that security researchers specifically go looking for, because a single flaw there can potentially compromise every user of every plugin built on top of the same verification mechanism, rather than requiring a separate exploit for each individual plugin. That's precisely the pattern Plugin4Shell represents: one underlying flaw class, reportedly present across four separate vendors' implementations of a conceptually similar verification step. As agentic coding tools continue absorbing more of the software supply chain into their own extension ecosystems, expect the plugin-verification layer specifically to keep attracting this kind of cross-vendor security research scrutiny.
Honest limitations
- AIR Security's exact disclosure timeline (when the vendors were first notified versus when the public disclosure went live) isn't fully detailed in the secondary coverage cited here — check the original disclosure for the complete responsible-disclosure timeline.
- The specific technical root cause of the SHA-pin bypass (whether it's a hash-comparison bug, a race condition, a caching issue, or something else) isn't fully detailed in secondary coverage — check AIR Security's original disclosure for the full technical writeup.
- No CVE number is confirmed in available secondary coverage as of this writing — verify current CVE assignment status against AIR Security's own disclosure page before citing one.
- Whether any real-world exploitation has occurred (versus this being a responsibly disclosed research finding) isn't confirmed in current reporting.
- GitHub's patch timeline is unknown — no announced date for a Copilot fix was found in available coverage.
Why "inherited credentials" is the detail that raises the stakes
The specific detail that a substituted plugin inherits the developer's full local and cloud credentials, not just some scoped-down execution context, is what separates Plugin4Shell from a merely annoying bug into a genuinely severe supply-chain risk. Most developers running an AI coding agent locally have that agent operating with meaningful access already granted for legitimate purposes — read/write access to their local repositories, often API keys or tokens for cloud services the agent is meant to help interact with, sometimes even deployment credentials for CI/CD pipelines the agent assists with. A plugin substitution attack that inherits all of that isn't limited to whatever narrow capability the original, legitimate plugin was designed to provide; it inherits the full blast radius of whatever the developer's coding agent session already has access to. That's the mechanism by which a vulnerability in a fairly narrow-sounding component — plugin-repository verification — becomes a much broader credential-theft and lateral-movement risk across a developer's entire local and cloud footprint.
What this means for builders
If you use any of these four tools with pinned plugin or dependency repositories, treat this as an active, unresolved risk category rather than a closed incident — Claude Code and Codex users should confirm they're on a patched version, GitHub Copilot users should audit and minimize third-party plugin-repository dependencies until a patch ships, and Gemini CLI users specifically need to plan a migration since Google has confirmed no fix is coming for the deprecated tool. More broadly, this is a concrete argument for not treating SHA-pinning alone as a sufficient supply-chain security guarantee for AI coding agents — pair it with least-privilege credential scoping for whatever your coding agent can access, so that even if a plugin-verification bypass like this one recurs, the blast radius of a successful exploit stays contained.
Related on explainx.ai
- MCP security: a complete guide
- Google's Gemini agents breached 3 real companies during a security test
- Researchers chained a libheif bug and an OpenAI SSO flaw — with Claude
- Shadow AI: workplace privacy risk guide
- Primary sources: AIR Security original disclosure · The Register · Help Net Security
This post is sourced to AIR Security's original disclosure and coverage from The Register and Help Net Security, dated September 17-18, 2026. Patch status for GitHub Copilot may have changed since publication — verify current status before making a security decision based on this post.
