Plugin4Shell AI Agent Vulnerability Bypassed Trusted Plugins, Leaving Two Coding Tools Unpatched

Plugin4Shell compromised a core safeguard across four AI coding agents, despite users following the expected process for installing reviewed plugins. Security company AIR says the flaw affected Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI. Its researchers demonstrated working remote code execution against all four products.

Anthropic and OpenAI released fixes after receiving AIR's disclosure. AIR reported no corresponding GitHub Copilot patch when it published its findings on September 17, 2026. It also said Google would not patch the affected Gemini CLI behavior, directing users toward Antigravity instead.

That uneven response is the central problem. Plugin marketplaces promise that review and commit pinning protect developers from code changes after approval. The Plugin4Shell AI agent vulnerability reportedly broke that promise without requiring a careless installation, suspicious approval, or new click.

Plugin4Shell Turned a Trusted Update Into Remote Code Execution

The attack targeted the plugin distribution process, not the language model deciding how to answer a prompt.

AI coding agents increasingly support plugins, skills, extensions, and other add-ons. These packages can customize workflows, connect services, or run code within development environments. They often inherit the agent's ability to access files, execute shell commands, and interact with authenticated systems.

That access makes an agent plugin closer to a local application than a passive text prompt. If malicious code reaches the plugin directory, it can operate with the permissions granted to the developer running the agent.

AIR says Plugin4Shell reached that point by bypassing SHA pinning. A SHA is a cryptographic identifier commonly used to name a specific Git commit. Pinning a plugin to that identifier should keep its installed code fixed, even when its repository changes later.

According to the Plugin4Shell research, the affected agents requested a pinned commit but failed to verify the commit actually checked out. An attacker controlling the upstream repository could exploit Git's name-resolution behavior and substitute different code.

The marketplace record could still display the expected commit identifier. The agent could also report a successful installation. However, the files in the working directory would come from an attacker-controlled branch rather than the reviewed commit.

AIR described two practical entry paths. An attacker could publish a legitimate plugin, build adoption, and turn the repository malicious during a later update. Alternatively, an attacker could take over the repository supporting an existing plugin.

The second path matters because it shifts responsibility away from individual plugin authors. A plugin can begin as a legitimate project and pass every review. Its repository can become hostile only after developers and security teams have trusted it.

AIR says the researchers found the issue in May 2026 and disclosed it to the four vendors in June. The company published its technical account on September 17. Help Net Security reported the findings the following day.

No public evidence cited by either organization showed Plugin4Shell being exploited against real victims before disclosure. The demonstrated impact comes from AIR's proof-of-concept testing, not a documented criminal campaign.

That distinction limits what can be claimed about immediate compromise. It does not reduce the importance of the broken control. A successful attack would execute code through a component that organizations had already reviewed and approved.

The issue also follows earlier AIR research into plugin distribution. The company says a test skill reached more than 26,000 agents before removal. Separate research reportedly identified 925 hijacked skills affecting 134,000 agents.

Those numbers come from AIR and have not been independently reproduced in the Plugin4Shell disclosure. They illustrate the researchers' broader argument: gaining distribution and compromising upstream repositories are realistic stages, not merely theoretical prerequisites.

How the Plugin4Shell AI Agent Vulnerability Bypassed SHA Pinning

Plugin4Shell worked because each affected agent trusted the requested Git reference instead of verifying the final checked-out commit.

Claude Code, Codex, and GitHub Copilot reportedly shared one variant. Their plugin installers cloned a repository and passed the pinned, 40-character commit identifier to git checkout.

Git permits branch names that resemble commit identifiers under many hosting configurations. When a name can identify both a branch and an object, Git may resolve it as a reference while printing an ambiguity warning.

An attacker controlling the plugin repository could create a branch named exactly like the pinned commit. The attacker would then make that branch the repository's default and point it toward malicious code.

The initial clone would bring down the attacker's default branch. The following checkout could resolve the apparent commit identifier to that local branch. The agent would then load or execute files different from those reviewed by the marketplace.

This technique does not work identically on every hosting service. GitHub blocks branch and tag names that look like full Git object identifiers, according to its branch-name restrictions.

However, AIR says Bitbucket and self-hosted Git services can accept such names. Some agent marketplaces officially support repositories hosted outside GitHub, leaving the wider configuration exposed.

Gemini CLI reportedly used a separate route to the same outcome. Its installer fetched the pinned commit and then ran a checkout against FETCH_HEAD, a Git reference normally pointing to fetched content.

AIR found that a repository could use FETCH_HEAD as its default branch name. The checkout could then resolve to that branch instead of the special file containing the fetched commit.

Both variants depended on a missing final comparison. After completing the checkout, the agent needed to resolve HEAD and verify that it equaled the marketplace's pinned SHA.

That check is small, but its location matters. A marketplace cannot confirm what a client eventually placed in its local working tree. The verification must happen inside the agent performing the clone and checkout.

The zero-click label comes from background updates. AIR says Claude Code and Codex automatically update installed plugins by default. A malicious replacement could therefore arrive after a marketplace changed its pin, without another installation decision.

The victim would not need to find a new malicious plugin. The attacker would target one already present on the machine and wait for the agent's update process.

Remote code execution, or RCE, means attacker-controlled instructions run on the target system. The resulting reach depends on the account, environment, sandbox, credentials, and network access available to the affected agent.

AIR describes the potential impact as equivalent to the access held by the employee running the tool. That is a worst-case description, not a universal measurement of every installation.

A tightly isolated agent might expose only a temporary workspace. A locally installed agent with cloud credentials, source repositories, signing keys, or production access creates a much larger potential blast radius.

This variability is why version inventory alone is insufficient. Security teams also need to know where each agent runs, which plugins it loads, and what credentials are available within that execution boundary.

Plugin Review Worked as Designed, but the Installed Code Still Changed

The core conflict is between the promise of immutable review and the reality of client-side Git resolution.

Software supply-chain controls often separate approval from execution. A reviewer evaluates a known version, records its digest, and allows systems to install only that version.

That model assumes the digest identifies the files that will execute. Plugin4Shell reportedly preserved the visible pin while breaking the connection between that pin and the final working tree.

This is more serious than warning users against unknown extensions. The researchers say the attack still works when a plugin comes from a trusted marketplace, passes review, and remains pinned.

Security guidance built only around marketplace reputation would therefore miss the vulnerable step. The attacker does not need to compromise the marketplace database if the local agent can be tricked during checkout.

The same limitation applies to internal plugin catalogs. An enterprise might review every package and mirror approved metadata. Those controls remain incomplete if employee clients do not validate the resolved commit.

AIR calls Plugin4Shell the first supply-chain vulnerability of the AI agent ecosystem. That wording is the company's characterization and deserves some caution.

AI development tools have already faced repository poisoning, prompt injection, malicious configuration files, and extension-related vulnerabilities. Plugin4Shell is narrower in one sense because it focuses on pinned agent add-ons and their update path.

Still, the mechanism exposes a distinct trust failure. It attacks how reviewed agent functionality travels from a repository to a developer's machine.

Recent research shows this is not an isolated pressure point. Wiz disclosed GhostApproval in July 2026 after testing six AI coding assistants. That issue used symbolic links to reach files outside expected workspace boundaries.

The GhostApproval findings affected products from Amazon, Anthropic, Augment, Cursor, Google, and Windsurf. Vendor responses varied, with several fixes and at least one disputed threat-model decision.

GhostApproval and Plugin4Shell use different technical primitives. One exploits path resolution through symbolic links. The other reportedly exploits Git reference resolution during plugin installation and updates.

The pattern connecting them is a gap between the user's visible decision and the system's real action. A path appears local but resolves elsewhere. A pin appears immutable but resolves to different code.

Permission prompts alone cannot repair that mismatch. Users cannot make informed decisions when the interface shows the trusted name while the underlying operation targets something else.

Anthropic has publicly described filesystem and network isolation as complementary safeguards for Claude Code. Its sandboxing model aims to prevent an injected process from reaching sensitive files or unauthorized network destinations.

Sandboxing can reduce the impact of malicious plugin code. It does not replace accurate package verification, especially when plugins run outside the same restrictions or receive broader permissions.

Enterprises therefore need two independent boundaries. The installation process must verify that reviewed code is actually installed. The runtime must limit what that code can reach after execution.

A failure in either layer should not automatically become a workstation or cloud-account compromise. Plugin4Shell matters because many agent deployments still combine mutable extensions with valuable local credentials.

Four Coding Agents Produced Four Different Security Outcomes

The disclosure exposed a fragmented patch process across tools that implement similar plugin workflows.

AIR says Anthropic fixed the Claude Code vulnerability in version 2.1.179. The company recorded June 17, 2026, as the date Anthropic confirmed the correction.

OpenAI fixed the affected Codex behavior in version 0.146.0, according to AIR. The research timeline says the company verified that release as fixed on August 12.

Users of those products should not assume automatic updates completed successfully. Managed workstations, offline environments, package locks, and internal distribution systems can leave older versions installed.

Organizations should query actual endpoints and compare their versions with the fixed releases. They should also restart long-running sessions if their deployment process does not replace active agent processes.

GitHub Copilot presents a different problem. AIR said Microsoft received the same vulnerability report but had not shipped a fix when the research became public.

GitHub had recently expanded centralized controls for agent operations. Its September 9 announcement said administrators could block, allow, or require approval for shell commands, file operations, and network domains through managed agent permissions.

Those controls can narrow consequences, but they are not evidence of a Plugin4Shell patch. An unpatched installer and a restrictive runtime policy address different stages of the attack.

Copilot administrators should therefore seek a product-specific advisory, fixed version, or vendor confirmation. Until then, organizations can suspend marketplace plugin updates or limit agents to approved repositories under their control.

Gemini CLI has the most complicated status. AIR says Google confirmed on August 4 that it would not patch the affected workflow and advised migration to Antigravity.

Google had already begun moving individual users from Gemini CLI to Antigravity CLI. A June announcement said Gemini CLI stopped serving requests for individual accounts while enterprise and API-key use remained available.

However, Google's earlier transition notice also said the open-source Gemini CLI project would continue receiving model updates, bug fixes, and security fixes for enterprise customers.

That public language does not align neatly with the claim that every Gemini CLI installation will remain vulnerable indefinitely. It leaves an important verification gap for administrators.

Google's September changelog shows Gemini CLI releases continuing after the consumer transition. It also lists security hardening unrelated to the precise checkout flaw. That activity does not establish a Plugin4Shell fix.

The cautious conclusion is narrower. AIR reported no Plugin4Shell patch for Gemini CLI at disclosure time and recommended Antigravity. Google continued maintaining parts of Gemini CLI for enterprise use, but no cited release note identifies this specific correction.

Enterprise users should not infer safety from general maintenance language. They need direct confirmation that their release verifies the final checked-out commit after installing or updating an extension.

They should also avoid treating migration as a simple rename. Moving skills, hooks, MCP servers, and credentials into a new agent can reproduce other risks if configurations transfer without review.

AIR says Antigravity does not use the plugin SHA-pinning mechanism exploited by Plugin4Shell. That means this specific path does not apply, based on the researchers' analysis.

It does not mean Antigravity is immune to malicious plugins, prompt injection, unsafe tools, or future supply-chain failures. Security teams should preserve the same isolation and least-privilege requirements after migration.

The four responses reveal a governance problem beyond this bug. Similar features can ship across multiple agents without shared disclosure conventions, common severity scoring, or synchronized remediation.

Developers must track separate changelogs and vendor statements. Enterprise administrators must then translate those uneven records into one enforceable security posture.

What Development Teams Should Change Immediately

The first priority is to stop vulnerable plugin updates, verify agent versions, and reduce the credentials available to every coding agent.

For Claude Code, organizations should move all installations to version 2.1.179 or later. For Codex, AIR identifies version 0.146.0 as the corrected release.

Teams should verify versions through endpoint inventory rather than surveys. Developers may use several coding agents across local terminals, IDE extensions, remote workspaces, and CI systems.

For GitHub Copilot, administrators should request explicit remediation guidance from GitHub or Microsoft. They should not treat unrelated permission improvements as confirmation that the checkout vulnerability has been fixed.

Where plugin functionality is not essential, disabling third-party marketplace packages offers the clearest temporary reduction. Organizations that cannot disable them should pause automatic updates and restrict repository sources.

Gemini CLI users should evaluate migration to Antigravity, particularly when using marketplace extensions. Enterprise customers should also request written confirmation about the status of their exact Gemini CLI release.

Removing an affected plugin after disclosure is useful but incomplete. A compromised package could have created persistence, modified startup files, copied credentials, or altered repositories before removal.

Incident responders should review plugin update history, Git activity, process execution, network connections, and sensitive file changes. The relevant time window begins before public disclosure if vulnerable auto-updates were active.

Teams should rotate credentials when telemetry indicates unexpected plugin code executed. Priority targets include source-control tokens, cloud credentials, package-publishing keys, signing material, and secrets stored in shell environments.

Credential scope matters as much as rotation. An AI coding agent should not inherit unrestricted production access merely because the developer launching it holds those permissions.

Separate agent identities make abnormal actions easier to contain and audit. Short-lived tokens also limit the value of credentials collected from a workstation.

Runtime isolation provides another layer. File access should default to the active project, while network access should use a narrow allowlist appropriate for the task.

Shell execution requires similar boundaries. A plugin that can invoke any command under a developer account can bypass many controls applied only to generated source code.

Organizations should test whether sandbox rules cover subprocesses created by plugins, hooks, package managers, and MCP servers. A restriction on the model's direct tools may not cover every extension process.

Plugin governance also needs stronger evidence. An internal catalog should store the reviewed commit, repository origin, resolved tree identifier, reviewer, approval date, and deployed version.

The installer should validate the resolved HEAD after checkout. If it does not match the approved commit, installation must stop rather than warn and continue.

Security teams can test this behavior without reproducing malicious execution. A controlled repository can present ambiguous references while the validation system checks whether installation fails closed.

The result should become part of procurement and internal acceptance testing. Vendors should be able to explain how their agents verify plugin content after cloning, fetching, and updating.

Teams also need a reliable record of why each plugin exists. A searchable engineering knowledge base can connect approvals, owners, incidents, and replacement decisions.

That documentation does not prevent exploitation. It shortens the time needed to identify affected teams and remove risky integrations when another disclosure appears.

Finally, developers should not be blamed for trusting an advertised pin. Plugin4Shell reportedly bypassed a control designed to make that trust reasonable.

The corrective action belongs across vendor code, enterprise policy, and runtime architecture. Training users to inspect every update cannot compensate for an installer executing different code than the approved digest.

Three Signals Will Show Whether Agent Plugin Security Is Improving

The next test is whether vendors convert this disclosure into verifiable installation controls instead of broader security promises.

The first signal is a specific GitHub Copilot remediation. Administrators should look for a security advisory, release identifier, or technical statement confirming post-checkout commit verification.

A general Copilot update will not answer the question. The relevant evidence is whether the client resolves the working tree's HEAD and compares it with the marketplace pin.

If GitHub documents that behavior and ships it across supported Copilot surfaces, the current patch gap will narrow. Continued silence would strengthen concerns about inconsistent vulnerability handling.

The second signal is Google's clarification for enterprise Gemini CLI users. Public transition language says enterprise access and security maintenance continue, while AIR reports no Plugin4Shell patch.

Google can resolve that tension by naming affected versions, explaining whether a fix exists, and defining support dates. A specific advisory would help teams decide between patching and migration.

If Gemini CLI receives verified commit checking, AIR's disclosure-time status becomes outdated. If Google confirms it will not, organizations should treat migration as a security requirement rather than a product preference.

The third signal is marketplace-level adoption of verifiable client behavior. Marketplaces cannot enforce the final checkout alone, but they can require compatible agents and reject unsafe repository configurations.

Useful changes would include signed manifests, immutable package artifacts, provenance attestations, and installation receipts containing the resolved commit. Each control should remain independently testable.

Agent vendors should also disclose whether plugins run inside the same sandbox as generated commands. A verified package can still be compromised upstream before review or contain an overlooked vulnerability.

The larger lesson is not that plugins are inherently unsafe. It is that autonomous agents turn packaging errors into actions performed with developer privileges.

Plugin4Shell reportedly crossed four competing products because their implementations relied on the same unchecked assumption. The requested Git identifier was treated as equivalent to the code actually installed.

Developers and security leaders should now ask a direct question of every coding-agent vendor: what proves that reviewed code is the code running on the machine?

Until Copilot and Gemini CLI have product-specific answers, affected organizations should limit plugin use, verify every agent version, and isolate credentials. Teams using patched Claude Code or Codex should still audit installed extensions and confirm that updates reached every endpoint.

The Plugin4Shell AI agent vulnerability is ultimately a test of operational visibility. Can your organization identify each agent, its plugins, its version, and its privileges before the next background update runs?