The Plugin Was Pinned to a Reviewed Commit. The Coding Agent Never Checked It Got That Commit

A week ago we wrote about an attacker who hijacked an AI coding-assistant session and used it to spread a worm across about a hundred repositories. The standard advice after incidents like that is the same every time: pin your dependencies. Lock each one to an exact, reviewed version, so that whatever the upstream author does next cannot reach you without a deliberate upgrade.

AI coding agents took that advice. Their plugin marketplaces pin each plugin to a 40-character git commit SHA, the most exact version identifier git has. Security teams reading the documentation could reasonably tick the box.

New research from AIR Security shows that in all four of the most widely used coding agents, the pin was a request, not a check.

What Plugin4Shell is

AIR Security published Plugin4Shell last week. It affects Anthropic's Claude Code, OpenAI's Codex, GitHub Copilot and Google's Gemini CLI. AIR describes it as zero-click remote code execution, and the result as "full compromise of the agent and the host it runs on."

The mechanism is a quirk of git that most developers never meet. When you run git checkout with something that looks like a commit hash, git first checks whether a branch has that name. If one does, git checks out the branch instead.

So an attacker who controls a plugin's repository can:

1. Create a branch whose name is exactly the pinned 40-character SHA.
2. Put malicious code on that branch and make it the repository's default.
3. Wait.

When the agent installs or updates the plugin, it asks git for the pinned commit and gets the attacker's branch. According to AIR, none of the four agents then confirmed that the code it checked out was the commit it asked for. Gemini CLI failed in a slightly different way, through a branch named FETCH_HEAD, but the outcome was the same.

The fix is one line, run by the agent after checkout: compare git rev-parse HEAD with the pinned SHA and abort if they differ. Only the agent can do this. The marketplace can pin whatever it likes, but it cannot make the agent check.

Why "zero-click" is accurate here

It is fair to ask how an attack that needs control of a plugin repository counts as zero-click. The answer is auto-update.

Background plugin updates are on by default in Claude Code and Codex. When a marketplace moves a plugin's pin to a newer reviewed commit, installed copies update themselves. If the attacker's branch is waiting under that name, the swap lands on every machine that has the plugin, with nobody pressing anything. The developer does not have to install anything new, approve a prompt or even open the agent that day.

AIR names two realistic ways to get control of a plugin repository:

• Publish something useful, then change it. A benign plugin passes marketplace review, gains users, and turns malicious later. AIR says one of its own test plugins reached more than 26,000 agents before it was pulled.
• Take over a repository people already trust. AIR's earlier SkillJacking research found 925 compromised skills reaching 134,000 agents through hijacked repositories.

In other words, the review step checked the right code, and the install step ran different code.

Who has fixed it

AIR says it found the flaw in May 2026 and disclosed it to all four vendors in June. As of publication:

Agent	Status
Claude Code	Fixed in 2.1.179 (confirmed 17 June)
OpenAI Codex	Fixed in 0.146.0 (verified 12 August)
GitHub Copilot	Not patched, according to AIR and Help Net Security
Gemini CLI	Will not be patched. Google is deprecating it and pointing users to Antigravity

The Gemini CLI answer deserves attention. "Deprecated" does not mean "uninstalled". Every developer laptop and CI runner that still has Gemini CLI now runs a coding agent that its vendor has said it will not fix. That is an asset-inventory problem, and it only gets solved if you know the tool is there.

What to do this week

None of this needs a new product. It needs an honest answer to one question: which coding agents are running in your organisation, at which versions, with which plugins?

1. Update Claude Code and Codex to at least 2.1.179 and 0.146.0. Confirm it on machines, not in policy documents. Background update of the agent itself is not the same as background update of its plugins.
2. For Copilot, restrict plugins to a short list you have reviewed, and consider turning off automatic plugin updates until Microsoft ships a fix.
3. Find and retire Gemini CLI, including on CI runners and shared build hosts, where nobody remembers installing it.
4. List the plugins actually installed, not just the ones on your approved list. The attack works through plugins people already have.
5. Treat a coding agent's host as holding everything the agent can reach. That usually means source code, cloud credentials in the environment, and SSH and git tokens. Scope those credentials as if the plugin might turn on you, because Plugin4Shell shows it can.

The wider lesson: controls you configure are not controls you verify

Plugin4Shell is a small bug with a large lesson. SHA pinning worked as designed everywhere except the last step, and the last step is the only one that matters. Marketplaces reviewed the right commit. Documentation described a strong guarantee. Buyers reasonably believed it. Nobody had tested whether the guarantee held on the machine that actually ran the code.

AI agents make this pattern more common, because they bring their own supply chains, their own update schedules and their own trust decisions, often outside the software inventory security teams already maintain. Governance for them has to start from what they do, observed and recorded, not from what their settings say they will do.

Where Obiguard fits

Governance AI will not patch Copilot, and it does not scan plugin repositories. Code that a malicious plugin runs directly on a developer's machine never passes through a model gateway, and we won't pretend otherwise. What Governance AI does is close the inventory and evidence gap that Plugin4Shell exposes, for the AI agents your organisation depends on.

An agent registry that is actually used. Governance AI keeps a living registry of every AI Use Case and Agent, and each agent reaches its model through a project Access Key. When coding agents route their model traffic through Obiguard, you can see which teams are running which agents, and when a vendor says "we will not fix this", you know where to look. If a host is compromised, you can revoke its key without cutting off everyone else.

Policy on what the agent is told to do. A malicious plugin or skill often works by steering the agent: telling it to run a command, fetch a script or send files somewhere. Those instructions and the resulting tool calls travel through the model's responses, and Policy Sets evaluate them as their own decision point. A keyword, regex or LLM-judge criterion can block or flag a tool call that pipes a download into a shell. The domain allow-list catches attempts to reach an unregistered endpoint before the request leaves.

A record you can check afterwards. Every prompt, response, tool call and policy decision is written to the Audit Ledger, with the agent and the initiating identity attached. If a plugin you trusted turns out to have changed under you, you can answer "what did our agents do in the days after the update?" from your own records instead of reconstructing it from laptops.

The question to take away

Plugin4Shell will be patched, eventually, in the agents whose vendors still support them. The more useful question outlasts it: for every control you rely on to keep AI agents safe, has anyone checked that it holds on the machine where the agent runs, and would you know if it didn't?

Explore Governance AI or talk to us about putting a registry, enforced policy and an audit trail around the coding agents your developers already use.