Your Agent Pinned a Plugin to a Hash. It Got the Branch.

A pin is a promise: install exactly this commit, nothing else. On September 17, 2026 three researchers at AIR Security published an advisory showing that four coding agents broke that promise. Each pinned a plugin to a commit hash and none checked that the commit it pinned was the one that landed; in three of the four, a repository owner who created a branch named after the hash got the branch checked out instead. The owner could then push whatever they liked to the branch, and every agent that auto-updated its plugins would install it without a prompt.

Two of the four had fixed it before the advisory went public. The rest of this post is about the part that outlives the patch: what git actually does when a name could be either a branch or a commit, how each extension system you rely on verifies the code it installs, and five questions to ask about your own setup. Every claim about the flaw is the researchers'; every claim about git is from git's own documentation.

The advisory, by Or Nevo, Dor Granat and Niv Hoffman, dates the discovery to May 2026, coordinated disclosure to the vendors to June, and publication to September 17. The name they gave the class is Plugin4Shell. The mechanism as they describe it is short: a plugin marketplace records a commit hash, the agent runs a checkout of that hash, and if the repository has a branch whose name is the same string, git checks out the branch instead. In the researchers' words, "when a name is both a valid ref and an object id, git prefers the ref…"

Three of the four agents shared that variant. Gemini CLI's was different: a repository whose default branch is named FETCH_HEAD overrides the commit the agent had just fetched. The researchers classify the result as a zero-click remote code execution, meaning in their description that no user interaction is needed once the agent updates. That is their severity call and we report it as such. The advisory does not cite a CVE and does not report any exploitation in the wild, and we found none elsewhere.

None of this is a git bug. It is documented behaviour. The git checkout reference describes the branch argument as follows: if the name, when prefixed with refs/heads/, is a valid ref, then that branch is checked out; otherwise, if it names a valid commit, HEAD becomes detached at that commit. A forty-character hexadecimal string is a perfectly legal branch name. So the moment such a branch exists, the first rule fires and the second is never reached.

git does try to warn. The configuration reference documents a setting, on by default, under which git will warn you when a ref name you passed is ambiguous and might match several refs. A warning on standard error is exactly the kind of signal an automated installer discards. The fix is the same in every product: after the checkout, read the commit that HEAD points at and refuse if it differs from the pin, or fetch the object by hash directly and never pass the string through name resolution at all.

Patch states below are those the advisory records, cross-checked against each vendor's own release record where one exists. The Claude Code version was dated from the npm registry. The Codex version was dated from its GitHub release. Neither vendor's notes name the advisory.

One detail from Claude Code's current documentation is worth knowing if you write a marketplace. Its plugin marketplace reference says that when a git-based plugin source sets both a ref and a sha, the sha is the effective pin and Claude Code fetches and checks out the pinned commit directly. The marketplace catalog itself, by contrast, supports a ref but not a sha, so the list of plugins can still move even when each plugin cannot. Version 2.1.277, released September 18, also fixed the installed-plugins record dropping the commit for official-marketplace plugins, which is the record a user would read to know what they actually have.

Agents install code from more places than plugin marketplaces. Each system below is classified by what its own documentation says the installer checks after download. One row is marked unverified, because we read no first-party statement in this pass for either system it names; they are named so that you check them, not skipped so that you forget.

The pattern across the verified rows is that the check happens on the artifact, not the name: a signature over the package, an attestation over the build, a commit compared against the pin. The unverified row is the one where a name is all there is. Our earlier posts on skill packs as a package ecosystem and on the lessons of an earlier plugin incident cover those two categories in depth.

You do not need to reproduce anything to know where you stand. Five questions, each answerable from a version number or a configuration file, cover the class.

The credential side of the same question, what a token lets an automated publisher do, is the subject of our companion post on stage-only npm tokens. And what still does not port when you move plugins between agents is in our plugins portability post. If you run agents that install their own extensions, our AI transformation service includes this check as part of an agent security review.