On September 17, 2026, Air disclosed Plugin4Shell: a plugin installer can request a reviewed Git commit yet install different code. Air reports the flaw in Claude Code, Codex, GitHub Copilot, and Gemini CLI. An attacker needs control of the plugin's source repository; background updates can then deliver the replacement to an existing installation.
Start with the installed plugin's source and the agent that fetched it. A marketplace label or a displayed version pin is insufficient evidence that the approved code reached the device. Deploy current approved agent releases, keep suspect plugins inactive, and preserve existing files before replacing them.
General Analysis has not reproduced this vulnerability. The procedure below combines the researcher's disclosure, OpenAI's public repair, and vendor documentation. It adds an installation-integrity review to the rollout controls in securing coding agents.
Identify the source behind the marketplace#
An administrator may approve a marketplace hosted on GitHub while an entry in that catalog points elsewhere. Anthropic's marketplace schema allows plugin sources to be separate repositories. Record both addresses: where the catalog lives and where each plugin's code comes from.
For the SHA-shaped branch variant, the source host changes the assessment. GitHub rejects branch and tag names that resemble 40-character Git object IDs. That blocks the reported name collision on GitHub. Do not extend this conclusion to a plugin fetched from a different host, or to unrelated malicious-plugin behavior.
Air describes a separate Gemini CLI variant involving FETCH_HEAD. A restriction on hash-shaped names does not establish protection against that variant. Assess it separately when reviewing GitHub-hosted extensions.
Consider a hypothetical company catalog containing two external plugins. One fetches its code from GitHub; the other fetches from an internal Git service. Both can display a commit pin, but only the first has the documented GitHub host restriction. The second needs its own host-policy and installer-verification evidence. The company's approval of the catalog does not answer either question.
See how your AI systems hold up under real attacks
General Analysis maps AI applications and agents, red teams prompts, retrieval, tools, MCP servers, browser actions, permissions, and business workflows, then turns findings into evidence your team can reproduce and retest.
Track the repair, with its evidence#
OpenAI's fix, merged July 22, resolves HEAD after a SHA-pinned checkout and rejects a mismatch with the requested commit. It explicitly leaves ref-name checkouts with their existing behavior. Choosing a branch or tag therefore remains a different policy decision from choosing a verified immutable commit.
| Client | Evidence available on September 18 | Administrative decision |
|---|---|---|
| Codex | Release 0.146.0 includes the public checkout-verification fix | Deploy a current approved release containing the repair; verify every launcher uses it |
| Claude Code | Air identifies 2.1.179 as fixed; the public changelog does not identify this repair | Treat the minimum as researcher-reported and deploy a current approved release |
| GitHub Copilot | Air reports no shipped fix at disclosure | Keep affected or unverified plugin sources inactive until the installer or source restriction is verified |
| Gemini CLI | Air reports no fix for its variant | Obtain a product-specific patch answer for the edition in use; isolate or disable affected extensions meanwhile |
The Claude, Copilot, and Gemini status entries come from Air's disclosure. They are not independent inspections of those clients' complete fixes. These are also historical minimums and dated findings, not instructions to downgrade an installation.
Google's May 19 transition announcement distinguishes consumer retirement from continuing enterprise and paid API access. It does not settle whether those continuing editions contain a Plugin4Shell repair. A general statement that Gemini CLI was retired is therefore inadequate evidence for an enterprise patch decision.
Capture the installation before changing it#
Use the normal device-management and incident-response process to collect the agent version, launcher, plugin configuration, and existing installation files. If compromise is suspected, collect through trusted endpoint tooling without starting the suspect agent or loading its plugins.
For ordinary inventory on an otherwise trusted installation, GitHub documents copilot plugin list --json and copilot plugin marketplace list --json. These distinguish installed plugins from registered catalogs. Inspect each catalog entry's source as well; a list of marketplace names alone cannot classify exposure.
Keep a record per plugin and installation scope. The following is an illustrative evidence template, not an agent configuration or a report of observed results. Fill it from your own inventory; null means unknown.
Code source: illustrative.
plugin_id: "example-plugin"
device_inventory_id: null
agent_executable: null
agent_version: null
installation_scope: null
catalog_url: null
plugin_source_url: null
approved_commit: null
installed_commit: null
installed_files_digest: null
collected_at: null
update_policy: null
source_host_restriction: null
disposition: "unverified"
A locally calculated digest identifies the files you collected. To determine whether those files were approved, compare them with a trustworthy expected artifact. Check manifest claims against the files too. If a cache lacks Git metadata, leave the installed commit unknown and verify the artifact through your normal process.
Preserve the catalog entry and approved revision from the period under review where available. Today's catalog may have moved on. Record the affected execution window from installation and process evidence; the public disclosure date is not the start of every device's exposure.
Pause the relevant update path without losing the patch#
Treat disabling plugin updates as temporary containment. It neither verifies existing files nor repairs the installer, and a later manual install can still fetch code.
Anthropic's current update documentation distinguishes official marketplaces, which normally update automatically, from third-party and local development marketplaces, which default to no automatic update. Managed settings can enable updates for an organization catalog. Review the effective setting on the device instead of assuming all installations share a default.
Avoid an indiscriminate global updater shutdown that also prevents delivery of the agent repair. Claude Code's DISABLE_AUTOUPDATER affects the client and marketplace updates, while command-source plugins follow a separate refresh path. Contain the suspect plugin or source through your managed controls, then deploy the approved client update through your normal software channel.
In Copilot CLI, added marketplaces can opt into session-start updates; built-in marketplace behavior and SDK/server sessions differ. User and managed settings matter. If a managed entry prevents a local disable, have the policy owner change the controlling entry. A rejected local toggle is not containment.
Verify a fresh copy before restoring access#
The public Codex repair checks the checkout when preparing a plugin. It does not establish that upgrading scans and removes every previously installed copy. Verify both the client update and the code that will load next.
For an unverified installation, our recommended recovery sequence is:
- Preserve the relevant files and records, then stop affected sessions and keep the plugin inactive.
- Replace the agent with an approved release containing the verified repair, or retain containment where a repair is unconfirmed.
- Reacquire the approved plugin through a trusted installation process. Confirm that the process replaced or independently verified the old cache rather than silently reusing it.
- Record the actual source, approved revision, resulting artifact evidence, and active version in a fresh session before restoring the plugin's access.
Review the plugin's executable components and the authority they receive. A correctly pinned plugin can still contain unsafe code or launch a connected service with excessive credentials. The MCP supply-chain threat model covers that broader review. The separate Codex sandbox disclosures also require their own component updates; closing this pinning issue does not close them.
Escalate an unexplained artifact mismatch or suspicious execution through incident response. Correlate installation time with endpoint process events, file changes, and downstream credential use. If evidence suggests credential access or persistence, follow the established containment and recovery procedure. An old version alone does not establish compromise, and a successful upgrade does not clear earlier activity.
Before restoring access, attach the approved client version, source revision, installed-artifact evidence, and fresh-session check to the change record. Document unresolved earlier activity in the incident record, with an owner for the remaining investigation.
