Air Security disclosed Plugin4Shell on September 17, 2026, describing a supply-chain weakness in the plugin installers of Claude Code, OpenAI Codex, GitHub Copilot and Gemini CLI. The vulnerable behavior is not an AI model obeying an injected prompt. It is a mismatch between the Git commit a plugin marketplace says it approved and the code an agent actually checks out. A repository operator who can manipulate the plugin's Git references may cause different code to be installed while the recorded commit pin remains unchanged. The researchers demonstrated the mechanism against the four named coding agents; the exact exposure depends on repository hosting, plugin source and client version.
The operational question is not simply whether an organization pins plugins. A reviewed commit is an intended identity; it becomes an effective safeguard only when the installer verifies the resolved checkout before running its contents. That distinction determines how teams should assess already installed extensions, automatic updates and the reliability of their development-agent controls. No publicly verified list of real-world victims or confirmed exploitation campaign was identified in the sources reviewed for this article, and Aipolix has not reproduced the attack independently.
The gap between a reviewed commit and installed code
In a conventional workflow, a marketplace reviews a plugin and records the Git commit hash of the approved version. The coding agent retrieves the repository and asks Git to check out that hash. Air found that affected installers treated a successful checkout command as proof that the approved commit had been selected. They did not resolve the final HEAD and compare its commit identity with the pin.
For Claude Code, Codex and Copilot, the researchers describe an ambiguity involving a branch named like the pinned 40-character commit hash. When an attacker controls the plugin repository, can designate that branch as its default and uses a Git host permitting such names, Git may resolve the identifier as a branch rather than the intended commit. The checked-out files can then differ from the approved snapshot. This is not an arbitrary compromise of every plugin: an attacker must control or compromise the relevant upstream repository, and the host must permit the reference behavior.
The hosting qualification is decisive. GitHub says it blocks branch and tag names resembling commit hashes, preventing that specific branch-name technique for repositories hosted on GitHub. Air identifies Bitbucket and certain self-hosted Git servers as potentially permitting it. A GitHub-hosted marketplace listing alone is not a reliable proxy for where every plugin's underlying source is hosted. Nor does GitHub's branch-name protection fix an agent's missing verification logic on another host.
Gemini CLI has a distinct variant. Air says its installer fetches the pinned commit but subsequently checks out FETCH_HEAD; a repository with a conflicting default branch of that name can redirect the checkout. That means restricting hexadecimal-looking branch names is not a universal mitigation for all implementations. The shared security invariant remains the identity of the final resolved commit, irrespective of the reference name used along the way.
Why a benign update can become an unattended install
The research describes a scenario in which a plugin first passes marketplace review, then receives a routine, still-benign version update. After a new commit is pinned, the malicious repository operator arranges an ambiguous Git reference so an affected installer resolves it to other code. On clients configured to update plugins automatically, an already installed extension could be replaced without another explicit approval. Air describes background automatic updates as the default in Claude Code and Codex; behavior on every deployment and configuration should not be assumed identical.
A malicious plugin can run with the filesystem and credential access available to the agent process, making the possible consequence more serious than an inaccurate generated answer. The disclosure calls the chain remote code execution, but that describes what a successfully swapped plugin could achieve, not evidence that every user of these products has been compromised. Marketplace review, a benign historical commit and a displayed version label are useful records, yet none alone proves which files reached an endpoint.
This yields an important audit distinction. A marketplace can verify what it approved. A source host can restrict dangerous reference names. Only the installing client, or another verifier at the installation boundary, can establish that the working tree actually corresponds to the exact approved commit. These controls protect different stages; reporting that a marketplace has implemented commit pinning is therefore not equivalent to demonstrating end-to-end integrity.
Vendor response: two reported fixes and two unresolved questions
Air reports that Anthropic fixed the issue in Claude Code 2.1.179, confirmed to the researchers on June 17. Its public release notes do not independently describe the Plugin4Shell fix, so this version attribution remains sourced to the researchers. OpenAI's response is more directly verifiable: a merged Codex change explains the Git ambiguity and adds an explicit comparison between the resolved HEAD and the requested commit. The official Codex 0.146.0 release includes that change. Organizations using older versions should verify their installed build and update to a release containing the fix.
For GitHub Copilot, Air said on September 17 that no client-side fix had shipped. The GitHub Copilot CLI release history checked for this article does not establish a subsequent Plugin4Shell-specific correction. That is not proof no private mitigation exists: the accurate public status is a researcher-reported unresolved client issue, with risk conditioned on how third-party plugin repositories are hosted. GitHub's response to The Register addressed protections on its own hosting service, while Air pointed out that external hosts remain relevant.
For Gemini CLI, Air reports that Google told it a fix for this flaw would not ship and recommended migration to Antigravity, whose different plugin mechanism is not exposed to this specific exploit. However, Google's official Gemini CLI documentation lists a stable v0.60.0 release dated September 15 with other safety improvements. The public evidence therefore does not justify saying that all Gemini CLI development has ceased or that a specific newer build is confirmed repaired. Teams still using it should seek explicit vendor guidance on this particular checkout flaw instead of treating unrelated hardening notes as a fix.
A verification plan for development teams
The practical response is to inventory the exact coding-agent versions, plugin sources and Git hosts in use, and identify any plugin installation or automatic-update path that can execute repository content. Teams can compare the approved commit recorded for each plugin with the resolved commit in its actual installed checkout, using trusted inspection procedures rather than trusting the installer's success message. For suspicious differences, preserve evidence and investigate before rerunning the plugin. Review automation settings and the credentials, filesystem locations and network access available to agents that load third-party code.
Where a documented client fix exists, install a patched release. Where it does not, temporarily restrict untrusted plugin sources and automatic updates according to local risk, and prefer source hosts with protections relevant to the documented branch variant while recognizing the separate Gemini case. These are risk-reduction measures, not proof that a vulnerable client has been fixed. Installing a patch also does not demonstrate that a previously replaced plugin was removed or that exposed credentials remain safe; the available sources do not establish automatic cleanup. If there is evidence of a malicious plugin having run, incident response should account for its actual privileges and potentially accessed secrets.
Plugin4Shell illustrates a precise failure of software provenance in agent systems. The pin is a claim about the approved artifact; checkout verification is the test of what the machine actually received; runtime permissions determine the consequence if that test fails. Treating those as separate acceptance criteria gives engineering teams a more useful response than either assuming every plugin is compromised or assuming a marketplace's review badge ends the investigation.