Plugin4Shell turns a pinned commit into an assertion. Verify the code that actually runs.
AIR Security found four major coding agents could install plugin code other than the marketplace-pinned commit. Agent supply-chain policy must verify resolved code at execution time, not trust a stored SHA alone.
On 17 September, AIR Security disclosed Plugin4Shell across Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI. The common failure is precise: each product used a pinned Git commit as an integrity control but did not reliably verify that the working tree actually resolved to that commit.
That changes the security meaning of a plugin pin. A marketplace can review clean code, record its SHA and still fail to guarantee what an agent later executes if checkout semantics can resolve the same-looking reference to attacker-controlled content.
The pin was metadata, not proof
AIR's research shows an attacker controlling a plugin repository can create a branch whose name matches a 40-character commit identifier. In affected flows, Git reference resolution can select that branch while the installation path still appears to honour the marketplace pin. Gemini CLI had a separate FETCH_HEAD variant.
The zero-click part comes from update behaviour rather than the initial install. AIR reports that Claude Code and Codex automatically update installed plugins. A plugin that was legitimate when approved can therefore become the delivery path later, after repository control changes or the upstream maintainer becomes malicious.
A pinned identifier is not an integrity control unless the runtime proves the bytes it executes resolve to that identifier.
Patch status is only half the control
AIR says Anthropic fixed Claude Code in version 2.1.179 and OpenAI fixed Codex in version 0.146.0. Its disclosure says Google deprecated Gemini CLI rather than patching it, while Microsoft had not provided an equivalent Copilot fix at publication time. Those states should be rechecked against current vendor guidance before operational decisions.
Upgrading patched clients matters, but Plugin4Shell exposes a broader governance gap. Agent plugins inherit the developer context around them: source trees, environment variables, local credentials and whatever internal services that workstation or runner can reach. Plugin provenance therefore belongs in the same control family as package signing and CI dependency policy.
Verify resolution, then reduce inherited authority
Enterprise controls should record the approved repository and immutable revision, resolve the installed plugin locally, and compare the resulting HEAD or equivalent content identity with the approved value before execution. Automatic updates should not silently expand the trusted code set.
The second control is blast radius. Run coding agents with scoped credentials, restrict plugin sources, inventory installed extensions and separate development convenience from production authority. A compromised plugin should encounter an execution boundary before it encounters a production secret.
The practitioner change is simple: stop treating marketplace approval plus a SHA as completed verification. The final integrity check belongs where code becomes executable, and the agent's surrounding permissions must assume that upstream trust can fail.
Sources
Written by the Devence Lab research team.
