Plugin4Shell: The Pin Was the Control, and the Pin Verified Nothing

Air Security published Plugin4Shell on 17 September 2026, and the coverage that followed described it as the first supply chain vulnerability of the AI agent ecosystem. The researchers found the bug in May 2026, built working proof of concept exploits against four agents, and disclosed to each vendor the following month. The affected products are Claude Code from Anthropic, Codex from OpenAI, GitHub Copilot from Microsoft and Gemini CLI from Google. It is rated high severity, it needs no click, no approval prompt and no reinstall, and at the time of publication the public writeups did not carry CVE identifiers. Anthropic shipped a fix in Claude Code 2.1.179 and OpenAI shipped one in Codex 0.146.0. Google responded that Gemini CLI is deprecated and will not be fixed, pointing users to Antigravity instead. GitHub had not shipped a fix for Copilot.

The mechanism is almost insultingly small, and that is what makes it worth understanding rather than just patching. These agents let you pin a plugin to a specific 40 character commit hash, which is the standard way to say that the code you reviewed is the code you will run. The agents then check out that commit and never verify that the checkout actually landed there. Git will resolve a name before it resolves an object under the right conditions, so an attacker who controls the plugin repository can create a branch whose name is the very commit hash you pinned to, and the checkout follows the branch. The pin still reads as intact in your configuration. The code underneath it is whatever the attacker put on that branch. Gemini CLI had a variant of the same shape, where a branch named FETCH_HEAD could redirect the checkout. In every case the flaw is not in the cryptography of the hash, which is fine, but in the absence of a single comparison after the fact between the commit you asked for and the commit you got.

The zero-click property comes from a product decision rather than from the bug. Claude Code and Codex update installed plugins in the background by default, which is a reasonable thing to do when you believe a pin means what it says. Combine automatic background updates with a pin that does not verify and you have a channel that silently replaces reviewed code on a developer workstation with no user action at all. The attacker path is the ordinary one for package ecosystems. Publish a plugin that is genuinely useful, let adoption build, then change what the pinned reference points at. Or skip the patience entirely and compromise the account of a maintainer whose plugin is already installed across a few thousand machines. Neither step requires anything novel, which is why the absence of confirmed exploitation in the wild is reassurance about the past rather than about the next quarter.

We wrote on 7 September about GitSpawn, where a repository that arrives as files can run attacker code the moment an agent opens it, and it would be easy to file this one next to it and move on. They are different problems and the difference is the whole point. GitSpawn is about untrusted input reaching a component nobody had modelled as a boundary. Plugin4Shell is about trusted input, deliberately reviewed, explicitly version locked by a person who did the right thing, quietly becoming different code. A user who ignored every piece of advice and a user who followed all of it were equally exposed here. That is the signature of a control failure rather than a user failure, and control failures are the ones that show up in an audit as a clean green tick right up until the day they do not.

Which brings us to the part that should bother compliance teams more than it will. SHA pinning is not just a security practice, it is an evidence artefact. It is what a great many organisations point at when an auditor asks how they ensure that only reviewed code runs in a development environment. The lock file, the pinned commit, the change record that names a specific hash: these are the documents that close the question. Plugin4Shell means that for four widely deployed agents, over a period of at least four months between discovery and disclosure and considerably longer in reality, that evidence described a control that was not doing the thing it was credited with doing. Nobody lied. The record said the plugin was pinned to a reviewed commit, and it was pinned to a reviewed commit. The agent simply did not check whether it had arrived there. An evidence artefact that documents intent rather than verified outcome is a category of finding worth going looking for elsewhere in your estate, because this will not be the only one.

The cold water matters here too, because the framing in some of the coverage runs ahead of the facts. This is not a flaw that lets an arbitrary stranger reach into your machine. It requires an attacker who controls or has compromised a plugin repository you have chosen to install, which is a meaningful precondition and the same precondition that governs every package registry risk you already carry. Two of the four agents are patched, and if you are on Claude Code 2.1.179 or later, or Codex 0.146.0 or later, the specific defect is closed. There is no public evidence of exploitation in the wild in the reporting to date. What should not be discounted is the tail. Copilot was unfixed at publication, so check the current state before assuming otherwise. Gemini CLI users were handed a migration rather than a patch, and a deprecation notice is not a remediation, which means anyone still running it in a pipeline is carrying a known unfixed remote code execution path until they move.

The framework mapping is unusually direct because none of the relevant controls are new or AI specific. ISO 27001 covers this across secure development, change management, the installation of software on operational systems, and the supplier relationship family, and the honest question for most statements of applicability is not whether those controls exist but whether anyone ever applied them to plugins that a developer installed into an agent without raising a ticket. ISO 42001 is where the tooling lifecycle belongs, because a management system for AI is the right place to record which agents your people run, what those agents are permitted to install, and who reassesses that when the vendor changes a default. SOC 2 asks the period question under change management, which is the hard one: not whether a pin was in place at the walkthrough, but whether every code path that reached a build environment across twelve months was the reviewed one. PCI DSS reaches this the moment a developer workstation can touch cardholder scope, since the standard expects an inventory of third party software components and a change control process that actually governs them. The EU AI Act angle is the logging duty, because a plugin version change that leaves no record is an action you cannot reconstruct afterwards. Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will hold the policy and collect evidence that you have one, and not one of them will tell you which plugins are installed in the coding agents on your engineering laptops, so this is a control you build and then evidence rather than one you buy.

The work is short and almost all of it survives whichever way the remaining patches land. Upgrade first and verify the version numbers rather than trusting an auto updater that was itself part of the problem. Then build the inventory nobody has, which is a list of every coding agent in use and every plugin installed into it, because you cannot reason about a supply chain you have not enumerated and most organisations genuinely do not know what is on those machines. Turn off background plugin updates where the setting exists, or gate them behind the same review any other dependency change gets, on the understanding that convenience was the delivery mechanism here. Treat plugin repositories as suppliers, with a named owner and a reason each one is installed, and remove the ones that exist because somebody tried them once. Make plugin version changes land in a log that a human or a query can read later, since the whole class of attack depends on a change that leaves no trace. And take the general lesson to the rest of your controls by asking, for each place where you rely on a pin, a hash or a signature, whether anything actually verifies the result or whether you are trusting that the tool did. The ISO 27001 and ISO 42001 guides on this site cover the change management, secure development, asset inventory and supplier control families this belongs in, the compliance readiness assessment will show you which of them you can currently evidence, and the policy templates library has the acceptable use, secure development and AI governance clauses to hang it on.