Plugin4Shell: when an approved AI plugin installs different code
Plugin4Shell exposed a gap between approving an AI coding plugin and checking the code delivered. A published Codex fix explains the missing verification.
In brief: Plugin4Shell concerns a gap between the plugin version that was approved and the code an AI coding tool actually installed. A recorded version number or identifier is useful only if the installed code matches it.
A plugin adds capabilities to a coding tool. It can bring in software maintained outside the company, making the installation process part of the software supply chain.
What the researchers found
Air Security’s report, dated 17 September, describes Plugin4Shell in Claude Code, Codex, GitHub Copilot and Gemini CLI. An attacker needed control of a plugin’s source repository. Under the conditions described, plugin updates could deliver malicious code without another user action.
The report describes a vulnerability, not a count of businesses confirmed to have been breached.
What locking a version is meant to do
Git records changes to software as commits. Each commit has an identifier, shown alongside its author and date in Git’s history.
Locking a plugin to a particular commit is intended to select that specific revision. Think of approving a particular edition of a document: its title alone does not tell you whether the copy you received is the edition you reviewed.
OpenAI’s published fix explains the failure in Codex. Git could interpret the requested identifier as a branch name and select different code. The fix checks the resulting commit and rejects a mismatch.
What has been corrected
The verification change appears in Codex 0.146.0’s release history. Air also reports a fix in Claude Code 2.1.179. At publication, Air reported no Copilot fix and said Google would not patch the deprecated Gemini CLI; those are the report’s dated status claims.
For a business using AI coding tools, the important distinction is between approving a component and verifying its delivery. This sits alongside the software supply-chain risks already seen around coding tools: trust in a tool also depends on the software it brings into the development environment.
