The issue, disclosed September 17 by AI-agent security company Air and first reported by The Register, attacks the mechanism meant to make plugin updates safe. Rather than persuading a developer to install a fresh malicious extension, an attacker who controls an already approved plugin repository can make the coding agent retrieve different code while its marketplace record still appears pinned to the previously reviewed commit.
For Windows developers and enterprise administrators, this is a supply-chain problem with a familiar outcome: code running in the context of the developer’s workstation can read the same source trees, cloud credentials, SSH keys, repositories, deployment tooling, and internal services that developer can reach. A coding agent’s plugin is not a passive prompt template. GitHub’s own Copilot plugin documentation shows that plugins can package skills, custom agents, hooks, MCP server configurations, and language-server commands, including PowerShell launch commands on Windows.
SHA pinning failed at the verification step
A full Git commit hash is supposed to be an immutable identifier. A marketplace can review a plugin at one commit, store that commit’s 40-character SHA, and direct the client to retrieve exactly that source revision later. That model protects users when an author moves a branch or tag after the marketplace approval process.
Air’s researchers, Or Nevo, Dor Granat, and Niv Hoffman, say the affected agents perform the checkout but fail to verify that the checked-out working tree actually corresponds to the promised object ID. Their proof of concept relies on Git’s handling of an ambiguous name: a repository can expose a branch whose name resembles the commit hash the client intended to retrieve. If the agent passes the bare hash-like string to Git rather than resolving and validating the commit object explicitly, Git can select the ref instead.
The important distinction is that the attack does not rewrite a legitimate commit hash. The attacker instead exploits a client that treats “Git reported success” as proof that it landed on the approved commit. The pinned value remains visible in the marketplace configuration, but the files that arrived locally can be different.
Git’s own revision documentation describes how ref names and object IDs can be interpreted through separate resolution rules. That is normal Git behavior; the vulnerability alleged here is the coding agents’ failure to follow the checkout with a verification that HEAD is the expected commit. This is why a marketplace cannot fully repair the flaw from its end. It can preserve the reviewed hash in its catalog, yet the client still has to prove that it executed that hash.
Why this can become zero-click code execution
Calling Plugin4Shell “zero-click” does not mean an internet-connected Copilot or Codex installation is automatically compromised. An attacker still needs control of the upstream repository for a plugin that a victim has already installed, or needs to get a benign plugin reviewed and adopted before turning on the malicious update path.
Once that prerequisite is met, however, the victim may need to do nothing. Air says Claude Code and Codex automatically update installed plugins by default. GitHub’s Copilot CLI documentation independently confirms that its built-in plugin marketplaces update plugins at the start of a session in a trusted working directory, and that enterprise-managed or user-added marketplaces can be configured for automatic refresh and plugin updates. GitHub also documents that Copilot marketplaces may be hosted on GitHub.com, another online Git hosting service, or local and shared storage.
That combination turns an ordinary marketplace refresh into the delivery event. A developer can open a terminal, start an agent session, or return to a project that centrally provisions plugins, and the updated package may be loaded with no new installation approval. In an enterprise deployment, administrators can automatically install plugins and define marketplace behavior through managed settings; that makes the potential blast radius depend heavily on how broadly a vulnerable plugin was assigned.
The execution consequences depend on the plugin components enabled by the client and the permissions granted to the agent session. But the risk should be evaluated as local code execution under the user’s account, not as a minor integrity mismatch. On Windows, that can include PowerShell-based plugin components, access to cached developer tokens, mapped drives, source checkouts, and any credentials or tools available to the user context.
GitHub’s mitigation does not settle the Copilot question
GitHub told The Register that Plugin4Shell attacks do not affect GitHub because the service blocks users from creating branch or tag names that resemble commit SHAs. Air agrees that this restriction prevents the demonstrated hash-shaped branch technique on GitHub-hosted repositories.
But that statement has a narrower scope than it initially appears to have. GitHub’s Copilot documentation expressly supports plugin marketplace sources beyond GitHub.com, while Air says Bitbucket and self-hosted Git platforms may permit the problematic ref names. The researchers therefore contend that GitHub Copilot remains vulnerable in supported configurations that retrieve marketplaces or plugins from those hosts.
This is the main unresolved point for Microsoft and GitHub customers. GitHub’s host-level restriction is a meaningful defense for repositories it hosts, but it is not a client-side verification fix. If Copilot accepts a plugin marketplace from another Git service, the relevant security question is whether the Copilot client verifies the final checked-out commit after resolving the marketplace pin. Air says it does not; Microsoft had not publicly described a code-level fix when the report was published.
Administrators should also avoid collapsing “Microsoft Copilot” and “GitHub Copilot” into one product in their inventories. The public reporting refers to GitHub Copilot’s plugin mechanism, while Air also says Microsoft Copilot supports outside marketplaces. Microsoft has not published enough technical detail to establish whether the same affected checkout path, version range, and mitigation behavior apply identically across every Copilot surface. That missing specificity matters for organizations using a mix of Copilot CLI, the Copilot app, cloud agents, and Microsoft-managed developer tooling.
The patch status creates three different response paths
Anthropic confirmed a fix in Claude Code 2.1.179 on June 17, according to Air’s disclosure timeline. OpenAI’s Codex 0.146.0 was verified fixed on August 12. Teams using those products should confirm that their developer machines and build images are actually running those versions or later; an outdated globally installed CLI, container image, developer workstation bootstrap script, or offline package mirror can leave the practical exposure unchanged.
Google told Air it would not patch Gemini CLI because the product is deprecated. Its recommended migration target is Antigravity, which Air says does not use the vulnerable marketplace SHA-pinning design. Gemini CLI users should treat migration as the durable remedy rather than waiting for a security update that Google has said will not arrive.
For GitHub Copilot, the lack of a documented client patch means the response is configuration-driven. GitHub’s documentation provides both a copilot plugin list command to inventory installed plugins and a copilot plugin marketplace list command to identify registered marketplaces. Those checks should be run first on developer workstations, shared Windows jump boxes, golden images, and centrally managed Copilot environments.
Until Microsoft documents an end-to-end client-side fix, organizations should take these steps:
- Remove or disable plugins from unneeded third-party marketplaces, especially marketplaces backed by Bitbucket, GitLab, or self-hosted Git services where branch-naming rules may differ from GitHub.com.
- Turn off automatic plugin updates where business requirements permit. In Copilot CLI, GitHub documents the
autoUpdatesetting and theCOPILOT_AUTO_UPDATE=falseenvironment variable; administrators should recognize that this reduces unattended delivery rather than correcting the underlying pin-validation problem. - Review enterprise-managed Copilot settings for automatically installed plugins and
extraKnownMarketplacesentries. A centrally required plugin can make a local user unable to disable or repoint it, so the remediation owner may be the platform team rather than the developer. - Validate plugin source code and repository ownership before re-enabling updates. A marketplace approval and a stored commit hash should no longer be treated as sufficient evidence that the files arriving on endpoints match what reviewers examined.
The real lesson is broader than one plugin format
Plugin4Shell is a sharp warning about a new class of enterprise software supply chain: agent extensions can blend executable code with instructions, hooks, model-facing skills, external tool configurations, and persistent local state. Security reviews that judge only a plugin’s initial content are inadequate if the update client cannot establish that later content is identical to the reviewed revision.
The immediate operational priority is straightforward. Patch Claude Code and Codex, retire Gemini CLI, and inventory every Copilot plugin marketplace that your organization permits. For Copilot deployments that can reach non-GitHub marketplace sources, GitHub’s repository naming control is not the same thing as a verified client fix; disable automatic updates or remove the affected marketplace paths until Microsoft explains exactly which clients validate the resolved commit and which do not.