Plugin4Shell Explained: How a Zero-Click Plugin Flaw Broke SHA Pinning in AI Coding Agents

Key Takeaways

• Plugin4Shell is an AI coding-agent plugin supply-chain vulnerability, not prompt injection and not a break of Git SHA cryptography.
• AIR Security disclosed the issue in September 2026 after demonstrating proof-of-concept attacks affecting Claude Code, OpenAI Codex, GitHub Copilot, and Gemini CLI.
• The core weakness is a verification gap: affected clients could request a pinned Git commit without proving that the checked-out HEAD actually matched that commit.
• OpenAI's Codex fix documents the same root cause and adds post-checkout SHA verification.
• AIR reports Claude Code 2.1.179+ and Codex 0.146.0+ as fixed.
• GitHub blocks branch and tag names that look like 40-character Git object IDs, which limits the main SHA-shaped-branch variant for GitHub-hosted repositories.
• The Gemini CLI proof of concept uses a different ambiguity involving FETCH_HEAD.
• As of September 27, 2026, no public Plugin4Shell CVE or confirmed in-the-wild exploitation was identified in the reviewed public reporting.

What Is Plugin4Shell?

Plugin4Shell is the name AIR Security gave to a plugin supply-chain weakness found in several major AI coding agents.

The expected security model is simple:

Plugin repository
      ↓
Marketplace review
      ↓
Approved commit SHA
      ↓
Client checks out that SHA
      ↓
Reviewed code executes

The problem is the last step. A successful Git checkout does not automatically prove that the resulting working tree corresponds to the exact object ID the marketplace intended to trust.

That means a marketplace can correctly pin a reviewed commit while a vulnerable client still materializes different code.

This is why Plugin4Shell is best understood as an artifact identity verification failure.

How the SHA-Pinning Bypass Works

For the Claude Code, Codex, and Copilot variant described by AIR, imagine the marketplace pins this fictional commit:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

A vulnerable installer might execute:

git clone <plugin-repository> ./
git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

If the repository host allows it, an attacker who controls the repository can create a branch with that exact 40-character hexadecimal name and point it at malicious code.

The same text can then identify two different things:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

1. the reviewed commit object
2. an attacker-controlled branch

The crucial failure is not the SHA itself. The client trusts revision resolution without verifying what became HEAD.

OpenAI addressed this in Codex by resolving HEAD after checkout and comparing it with the expected commit. If the values differ, installation fails.

Plugin4Shell therefore does not break Git hashes. It breaks the assumption that requesting a hash guarantees the expected object was checked out.

Why It Can Be Zero-Click

The attack becomes more serious when installed plugins update automatically.

A plausible sequence is:

1. A legitimate plugin is published and reviewed.
2. Users install the trusted version.
3. A later update receives a new approved SHA.
4. The repository owner, or an attacker who compromises the repository, prepares the ambiguous Git state.
5. The agent automatically updates the plugin.
6. Malicious code reaches the developer environment without a new manual install decision.

That is the basis for the zero-click description.

However, zero-click does not mean any attacker on the internet can instantly compromise any coding agent. The attacker generally needs control of the plugin repository or equivalent write access first.

The main threat models are:

• Malicious publisher: a trusted plugin later performs a rug pull.
• Repository takeover: an attacker compromises a legitimate maintainer.
• Compromised enterprise source: an internal plugin repository or Git host is taken over.

Why AI Coding-Agent Plugins Raise the Stakes

Coding agents often run with more authority than ordinary web applications.

Depending on configuration, a plugin may interact with:

• source repositories;
• local files;
• shell commands;
• environment variables;
• API tokens;
• cloud credentials;
• SSH credentials;
• MCP servers;
• deployment workflows.

That makes a plugin-integrity failure potentially equivalent to arbitrary code execution within the agent's permission boundary.

The important security principle is least privilege. A compromised agent inside an isolated development container with short-lived credentials has a smaller blast radius than an agent running directly on a developer workstation with production credentials.

Affected Tools and Current Status

The following reflects public information available as of September 27, 2026.

The Codex case is especially well documented because OpenAI's public code change explicitly verifies the resolved commit after checkout.

Why GitHub Hosting Changes the Risk

The main Claude Code, Codex, and Copilot proof of concept requires a Git host that permits branch names that look exactly like 40-character object IDs.

GitHub restricts those names.

That means the primary SHA-shaped-branch technique is blocked for repositories hosted on GitHub.

A simplified matrix:

This is useful defense in depth, but it is not a complete client-side fix.

A secure installer should remain safe even when the repository is hosted on a permissive Git server.

Gemini CLI Uses a Different Variant

The Gemini CLI proof of concept is important because it shows that Plugin4Shell is broader than one SHA-shaped branch trick.

A simplified flow looks like this:

git clone --depth 1 <plugin-repository> ./
git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b
git checkout FETCH_HEAD

AIR reported that a conflicting branch named FETCH_HEAD could interfere with the later checkout and cause Git to resolve a different target than the installer intended.

This means GitHub's 40-character hexadecimal branch restriction does not address the Gemini-specific path.

The general solution is still the same: verify the final resolved commit after checkout.

The Correct Security Check

The installer should treat the expected commit as an invariant:

EXPECTED_SHA="41d0bc0a4aeb2fbf797dacea39e876d98c95024b"
ACTUAL_SHA="$(git rev-parse HEAD)"

if [ "$ACTUAL_SHA" != "$EXPECTED_SHA" ]; then
  echo "Plugin checkout verification failed"
  exit 1
fi

The trust model should be:

expected SHA
     ↓
checkout
     ↓
resolve HEAD
     ↓
HEAD == expected SHA?
   /            \
 yes             no
  ↓               ↓
continue         abort

This is safer than attempting to blacklist individual dangerous ref names.

The installer verifies the artifact it actually materialized rather than trusting the revision expression it attempted to use.

What Plugin4Shell Is Not

It Is Not a SHA Collision

The attack does not require generating two commits with the same cryptographic hash.

The expected commit can remain completely valid.

It Is Not Prompt Injection

The attack happens in plugin source retrieval and checkout logic, below the language-model layer.

It Does Not Affect Every User Equally

Exposure depends on whether relevant plugins are installed, where their repositories are hosted, whether the client is patched, how updates work, and whether an attacker controls the plugin source.

It Is Not Evidence of Widespread Active Exploitation

Researchers demonstrated proof-of-concept attacks. That is different from documented attacks against real-world victims.

As of September 27, 2026, the reviewed public reporting does not establish widespread in-the-wild exploitation.

Does Plugin4Shell Have a CVE?

No public Plugin4Shell CVE was identified in the sources reviewed for this article as of September 27, 2026.

That does not reduce the technical significance of the issue. CVE assignment is an identification and coordination mechanism, not a requirement for a vulnerability to be serious.

Security teams should avoid inventing a CVE-2026-XXXX identifier or presenting an unofficial CVSS score as authoritative.

Who Should Be Most Concerned?

The highest-priority environments to review are:

• older Claude Code or Codex installations that predate the reported fixes;
• third-party marketplaces using non-GitHub repositories;
• self-hosted Git services that allow SHA-shaped refs;
• enterprise plugin ecosystems with automatic updates;
• legacy Gemini CLI environments using extensions;
• developer machines where coding agents hold broad shell, cloud, or deployment credentials.

Users without third-party plugins have substantially less direct exposure to this specific attack path.

How Developers Should Respond

• Update Claude Code and Codex to versions containing the reported fixes.
• Inventory installed plugins and record their source repositories and Git hosts.
• Review non-GitHub plugin sources first, because GitHub blocks the main 40-hex branch-name technique.
• Check self-hosted Git rules rather than assuming they match GitHub.
• Audit automatic updates because update mechanisms can turn repository compromise into silent code delivery.
• Reduce agent privileges with isolated environments, short-lived credentials, and restricted cloud roles.
• Verify repository ownership changes and unexpected maintainer transfers.
• Rotate credentials if malicious plugin execution is suspected.

What Plugin Marketplace Maintainers Should Change

A stronger marketplace design should include:

1. Immutable source identity — store the exact reviewed revision or content digest.
2. Post-checkout verification — compare the actual HEAD with the expected commit.
3. Artifact integrity — prefer content-addressed or signed artifacts where practical.
4. Publisher security — protect maintainer and repository ownership against takeover.
5. Update transparency — make automatic updates auditable.
6. Least privilege — minimize filesystem, shell, network, and credential access.
7. Rapid revocation — support emergency disabling of compromised plugins.

The central lesson is:

reviewed reference
        ≠
verified runtime artifact

Security depends on verifying what actually executes.

Why Plugin4Shell Matters Beyond These Four Tools

AI developer ecosystems are rapidly expanding into plugins, skills, hooks, subagents, MCP integrations, and other extension formats.

Each extension system creates four important security questions:

• Who controls the source?
• What exact artifact was reviewed?
• Can installation or update resolve to a different artifact?
• What permissions does the extension receive after execution?

Plugin4Shell demonstrates that version pinning alone is not enough.

Future agent security will increasingly depend on provenance, artifact identity, update integrity, and least privilege.

Frequently Asked Questions

Is Plugin4Shell a Git vulnerability?

It is better described as unsafe use of Git revision resolution by plugin installers. The public evidence does not show a new cryptographic break in Git.

Is Codex still vulnerable?

AIR reports Codex 0.146.0+ as fixed. OpenAI's public patch verifies that the actual HEAD matches the expected pinned commit.

Is Claude Code still vulnerable?

AIR reports Claude Code 2.1.179+ as fixed.

Are GitHub-hosted plugins safe?

GitHub blocks the main 40-character SHA-shaped branch technique, which materially reduces exposure to that specific variant. It does not eliminate every possible plugin supply-chain risk.

Has Plugin4Shell been exploited in the wild?

No confirmed real-world exploitation was identified in the reviewed public reporting as of September 27, 2026.

Conclusion

Plugin4Shell matters because it breaks a security assumption developers usually consider fundamental: a pinned commit should identify immutable code.

The Git SHA was not defeated. The failure happened because affected clients did not always verify that the code placed on disk actually matched the pinned revision.

For developers, the immediate response is clear: update patched agents, audit third-party plugins, pay special attention to non-GitHub and self-hosted sources, and reduce the privileges available to agent extensions.

For tool builders, the larger lesson is even more important. A marketplace cannot treat a version identifier as a security guarantee unless the client verifies the final artifact that actually executes.