Plugin4Shell – Zero Click RCE Vulnerability found in top four coding agents

A newly disclosed vulnerability dubbed Plugin4Shell enables zero-click remote code execution in Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI by bypassing plugin SHA pinning, according to the security researchers behind the finding. The flaw lets an attacker who controls a plugin's repository make the agent's checkout resolve to malicious code while the pinned commit still appears honored, and because agents auto-update plugins in the background — the default in Claude Code and Codex — no user interaction is required. The researchers frame Plugin4Shell as the first supply chain vulnerability of the AI agent ecosystem, noting that enterprises using Air Marketplace and Air Filter were not affected, and that only an agent-side fix can restore the pinning guarantee because the pin is resolved inside the agent.

Agent add-ons - the plugins and skills you install into an AI agent - are effectively applications, and enterprises overwhelmingly install them from open community marketplaces rather than a vetted, enterprise-grade one. The agent runs with the full capabilities of the employee operating it: the same access to sensitive data, internal systems, and production environments. Plugins inherit those permissions by default. A malicious plugin therefore does not need to escalate anything: it achieves full remote code execution on the employee's machine and hands an attacker the same reach over the enterprise's crown jewels that the employee has. The story so far This is the third act of a story we have been telling. In The Story of Skills we showed how easy it is to get in: we built a malicious skill, watched it go viral, and seized control of over 26,000 agents - planting your code in a marketplace people trust is not the hard part. In SkillJacking we showed you don't even need to plant anything: 925 skills already in use were hijacked out from under their maintainers, affecting 134,000 agents, by taking over the repositories behind them. The industry's answer to exactly this kind of rug-pull is SHA pinning - review the code at one commit, pin that commit, and trust that the pinned commit is what runs forever after. Plugin4Shell is the story of that boundary failing. It is a plugin SHA-pinning bypass: the agent checks out the exact commit the marketplace pinned but never verifies it landed there, so an attacker who controls the plugin's repo makes the checkout resolve to malicious code while the pin still looks honored. The result is zero-click remote code execution across Claude Code, Codex, GitHub Copilot, and Gemini CLI. <sup Enterprises using Air Marketplace and Air Filter were not affected by Plugin4Shell.</sup Why Plugin4Shell is unique - It is the first supply chain vulnerability of the AI agent ecosystem. Previous agent security work has targeted the model or the agent itself. Plugin4Shell attacks the distribution layer underneath them, the marketplaces through which agent add-ons reach millions of machines. - Zero-click remote code execution. No user interaction of any kind is required. The result is full compromise of the agent and the host it runs on, and with it full access to every asset and every piece of data the agent can reach. - One flaw, and every major lab made it. The same design error sits in every affected agent - not an implementation slip in one product, but a single mistake repeated across the industry, leaving millions of agents vulnerable. - A marketplace cannot fully close this. The pin is resolved inside the agent, so only an agent-side fix restores the guarantee. A marketplace can blunt the branch-name variant by allowing only hosts that reject SHA-shaped names - effectively, GitHub-only - but that bans hosts the agents officially support, and does nothing for Gemini CLI's variant. Who is affected and what is the impact Anyone running a major coding agent that installs plugins from a marketplace is exposed. That is Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI. The exposure is not limited to users who install plugins carelessly: the victim only has to have a plugin installed, from a marketplace they trust, that was reviewed and pinned exactly as the security model intends. Doing the right thing does not protect you. Organizations that go beyond a community marketplace - reviewing plugins and pinning them to a reviewed commit - rely on SHA pinning as their safeguard, and Plugin4Shell quietly nullifies it: review passes, the pin is written, and different code installs. Every downstream vetting process built on pinning inherits the failure. What makes it 0-click is plugin auto-update. Agents update installed plugins in the background - in Claude Code and Codex this is the default - so when the pinned commit is swapped upstream, a plugin the user already trusts and already has installed is replaced with a malicious version without any user interaction: no install step, no prompt, nothing to notice. The attacker does not need to persuade anyone to install anything new. They only need the benign plugin to already be there. How it can be exploited There are two paths, and neither requires the attacker to control the marketplace. Method 1: publish a plugin, then turn it malicious. The attacker contributes a genuinely benign plugin to a trusted marketplace, passes review, and later swaps its content for a malicious version. Getting a plugin into a top marketplace is not hypothetical - we've already done it The Story of Skills . Method 2: hijack a legitimate author's plugin. The attacker takes over the repository behind a plugin someone else wrote and the marketplace already trusts, then exploits Plugin4Shell to force the malicious version onto every agent that has it installed - bypassing the version pinning that exists precisely to stop this. We demonstrated the takeover step in the wild in SkillJacking and RepoJacking. Together, the chain is proven end to end - takeovers happen at scale, and Plugin4Shell defeats the mechanism built to contain them. The attack, end to end: Technical deep dive Every affected agent checks out the pinned commit but never checks that it actually landed there. That one missing check is the whole bug - and git gives an attacker two ways to exploit it. The pinned commit becomes a branch - Claude Code, Codex, GitHub Copilot These agents clone the plugin repository and check out the pinned SHA: git clone <plugin repo ./ git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa The attacker, who now controls the upstream repository, creates a branch whose name is the exact 40-hex pinned SHA and makes it the repository's default, so the plain git clone above brings it down as a local branch of that name. git checkout then resolves the pinned SHA to that branch: when a name is both a valid ref and an object id, git prefers the ref and only prints a refname is ambiguous warning - so it never matters whether the pinned commit is still present, the branch is what gets checked out. Two conditions make it work: nothing blocks a branch from being named like a hash git's own git check-ref-format accepts 40-hex names, and hosts that follow the protocol accept them too , and the branch must be the repository's default - a non-default branch is fetched only as a remote-tracking ref, and the checkout would fall back to the commit. The working tree is now attacker-controlled, and the agent reports a successful install at the pinned commit. This is not only an install-time bug, and that is what makes it zero-click: the same git checkout re-runs on background auto-update - the default in Claude Code and Codex - so when the marketplace bumps the pinned SHA, the swap reaches already-installed plugins with no user action. This only works where a branch can be named like a hash. That is git's default behavior, but some hosts forbid it - GitHub rejects a 40-hex branch name outright - while others, Bitbucket among them, and any self-hosted git server, allow it. Marketplaces on those hosts are a supported configuration; Anthropic's own documentation lists Bitbucket and self-hosted git as valid marketplace backends. The pin is fetched but never checked out - Gemini CLI Gemini pins with --ref and installs in three steps: git clone --depth 1 <plugin repo ./ git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b git checkout FETCH HEAD The fetch retrieves the correct commit and records it in .git/FETCH HEAD . But git checkout FETCH HEAD does not have to read that file: if the repository's default branch is itself named FETCH HEAD , the checkout resolves to the branch, and the fetched commit is silently discarded in favor of attacker-controlled default-branch content. One assertion closes both variants: after checkout, resolve the commit actually in the working tree and abort unless it equals the pinned SHA. test "$ git rev-parse HEAD " = "<pinned-sha " || abort It has to check the resolved HEAD , not the ref that was requested - that distinction is exactly what the Gemini variant slips through. And it has to run inside the agent: the pin is resolved on the client, so no marketplace can enforce the guarantee it advertises. How it can be mitigated Because the pin is resolved inside the agent, no marketplace can enforce it - the fix has to ship in the agent, and updating is the only complete mitigation where one exists: - Claude Code - Anthropic patched it after our disclosure, in 2.1.179. - Codex - OpenAI patched it after our disclosure, in 0.146.0. - GitHub Copilot - we disclosed the same flaw to Microsoft, which has not shipped a fix, so users have no patch. - Gemini CLI - Google has deprecated the Gemini CLI and will not patch it, so every install stays vulnerable for good; those users should migrate to Antigravity, which this attack does not reach - it has no marketplace plugin SHA pinning to bypass. Timeline <sup Enterprises using Air Marketplace and Air Filter were not affected by Plugin4Shell. Book a demo to learn more about how can Air protect from agentic supply chain vulnerabilities.</sup