Plugin4Shell: the zero-click RCE that arrived through AI coding agent plugins
Opening
In September 2026, AIR Security disclosed a vulnerability class affecting the plugin installation mechanism shared by four major AI coding agents. Commentators reached for a familiar comparison and called it the Log4Shell of the agent ecosystem. The name Plugin4Shell stuck. The essential property is that a developer installs a plugin the way they always have, and code runs without any further interaction.
Technical context
The four affected products are the plugins or extension mechanisms of mainstream AI coding assistants, with affected versions including Claude Code below 2.1.179 and Codex below 0.146.0, alongside GitHub Copilot and Gemini CLI. The shared weakness is in how plugin packages are resolved and installed: metadata supplied by the package is trusted during installation, and that trust is sufficient to influence what gets executed.
Why zero-click matters here is a matter of context. A coding agent runs on a developer workstation with the developer's credentials, source code access, cloud tokens, and often production deployment permissions. That is a higher-value position than a typical application server, because it sits upstream of everything the organisation builds and ships.
Disclosure on 18 September 2026 placed the issue in the same category as two other recent findings against the same ecosystem: GitSpawn, which abused Git configuration keys to execute code before a trust prompt appeared, and the broader pattern of malicious content in agent-readable files. Taken together, they describe an ecosystem where the execution boundary between a developer's instructions and third-party content is not well defended.
Defensive implications
Update the agents and confirm versions explicitly. Because the affected mechanism is the plugin installation path rather than the model or the chat interface, an agent can appear to be current while still running an affected installer. Verify against the fixed version list.
Review installed plugins as software supply chain. Maintain a signed allowlist of approved plugins and their versions, resolve installations through an internal mirror rather than directly from public registries, and require provenance attestation for anything installed in a build or release context. Where the agent supports it, disable automatic plugin installation entirely and require an explicit, logged action.
Constrain what the agent can reach. Run agents that process untrusted repositories in a container or virtual machine with no ambient cloud credentials, and issue short-lived scoped tokens rather than long-lived keys that grant broad access. Keep repository write permissions separate from read permissions so that a compromised agent cannot push to a protected branch.
Monitor at the process level. An agent or package manager spawning a shell, a build tool making unexpected outbound connections, or a plugin installation that writes outside its own directory are all observable events. Recording them gives an investigation a starting point that text-based logging of model output does not.
The strategic point is that agent tooling has become production infrastructure without acquiring production controls. Inventory it alongside build servers and deployment pipelines, apply the same change management, and expect the next disclosure in this category to follow the same pattern: trusted metadata, execution before confirmation, and a workstation with more privileges than anyone intended.
Top comments (0)