What was reported, and what “zero-click” really means
The report describes a remote code execution path in four widely used AI coding agents that requires no meaningful user interaction. The Plugin4Shell research disclosure identifies the affected products as Claude Code, Codex, Copilot and Gemini CLI. Its reported mechanism is specific: a trusted plugin is replaced or checked out at unintended content even though a SHA pin is present, allowing the altered content to reach the agent's execution path. At the time of disclosure, Claude Code and Gemini CLI had shipped patches. We do not treat that report alone as evidence that Codex or Copilot remained unpatched; consult the current vendor advisories for their status as of 18 September 2026. If one of them sits in your toolchain, the vendor advisory is what you should read — not a weekend summary written from a news item, including this one.
“Zero-click” deserves a precise reading, because it is routinely misunderstood. In this incident, it refers to the reported plugin replacement or checkout path, not to every kind of untrusted text an agent might consume. The disclosure does not establish that an arbitrary repository file, issue, pull request, web page or rules file independently triggers this specific RCE. Those inputs are relevant to the wider prompt-injection and agent-security discussion, but they should not be presented as the verified Plugin4Shell mechanism.
Why coding agents are structurally exposed
The uncomfortable part of this story is that the root cause is not a sloppy string handler. It is the design.
An AI coding agent is a language model wired to tools: a shell, a file system, a package manager, a browser, a Git client. To be useful, it must accept text from the outside world as input. To be safe, it would have to never treat that text as instructions. Those two requirements contradict each other, and there is currently no universal prevention: the model has one input channel, and instructions and data arrive through it together. Prompt injection is a broader delivery mechanism. Remote code execution is the impact. What does exist is a growing set of layered mitigations — sandboxing, tool allowlists, human approval steps, content filters and least-privilege identities — that reduce practical risk even though no single control eliminates injection across arbitrary contexts.
Three amplifiers turn a bad day into a breached workstation:
- Identity. The agent typically runs with the developer’s own rights — their SSH keys, their cloud tokens in environment variables, their access to private registries. There is no separate least-privilege identity unless you deliberately create one.
- Blast radius. Auto-run modes and “skip approvals” switches exist because permission prompts are annoying. They also remove the last human checkpoint between untrusted input and a shell command.
- Supply chain. MCP servers, rules files and editor extensions are related attack classes because they can introduce third-party content into an agent or editor workflow. Tool poisoning, instructions hidden in project rules files, auto-execution bugs in editors and malicious or compromised extensions have all been discussed as separate security risks; they are not established parts of the Plugin4Shell incident itself.
What makes this particular report notable is the combination of a trusted plugin, a bypass involving its pinned SHA and code execution without a meaningful user approval step. The lesson is narrower — and more useful — than treating every repository, issue tracker or web page as proof of this exact attack path: the integrity checks and permissions around agent plugins need to be reviewed as carefully as the model prompts themselves.
Europe: what the Cyber Resilience Act actually triggers
The European regulation most relevant here is not the AI Act. It is the Cyber Resilience Act — Regulation (EU) 2024/2847, in force since December 2024, with obligations phased in over roughly three years.
From 11 September 2026, manufacturers within the CRA’s scope — those placing products with digital elements on the EU market — must report actively exploited vulnerabilities, or qualifying severe incidents, under the prescribed notification timelines: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days. The bulk of the framework — vulnerability handling, secure-by-default configuration, technical documentation, CE marking — applies from 11 December 2027.
This matters for the current story in a very concrete way. An unpatched vulnerability does not by itself start the clock. A defect becomes reportable only if it is being actively exploited, or if it leads to a qualifying severe incident, and only for a vendor that is within the CRA’s scope. For those cases the clock does not negotiate over how hard the fix is. And unlike most AI-specific rules, the Cyber Resilience Act gives European authorities a lever with real teeth: market access.
| Rule | Who it hits | Practical consequence |
|---|---|---|
| Cyber Resilience Act (EU) 2024/2847 | Vendors selling software with digital elements in the EU | 24-hour early warning for actively exploited vulnerabilities or qualifying severe incidents from 11 Sep 2026; an unpatched flaw alone does not trigger it; full obligations from 11 Dec 2027 |
| AI Act (EU) 2024/1689, Art. 15 | Providers of high-risk AI systems | Cybersecurity and robustness requirements — but most coding assistants are not classified high-risk, so it rarely applies here |
| GDPR, Art. 32 and Art. 33 | Anyone processing personal data with an agent in the loop | If the agent is compromised and a personal-data breach occurs, the supervisory authority must be notified within 72 hours only where the GDPR’s reporting conditions are met |
| NIS2 | Essential and important entities | Incident reporting duties can apply to a significant incident affecting an in-scope entity; they do not automatically apply to every compromised developer workstation |
What the AI Act does and does not do here
It is worth being blunt, because there is a lot of loose talk about the AI Act in security discussions. Article 15 requires high-risk AI systems to be resilient against unauthorised third parties exploiting vulnerabilities. A coding assistant is, in most enterprise deployments, not a high-risk AI system. So the AI Act will not force most vendors to fix a zero-click RCE in their agent. The pressure comes from the Cyber Resilience Act, from GDPR exposure on the customer side, and from procurement — enterprise security questionnaires move vendor behaviour faster than any single regulation.
For European teams the practical translation is short: the compliance story sits downstream of an operational one. If developers run agents with production credentials, the first question an auditor will ask is not which regulation applies. It is what you documented as your technical and organisational measures — and whether anyone actually tested them.
What we would do this week
In our own production pipelines and on the AI Arena rig, we treat an agent like any other piece of untrusted code executed with a developer’s identity. Nothing about that is exotic — it is the discipline we applied to CI runners a decade ago, applied to something that talks back.
- Contain it. Run agents in a container or VM with the repository mounted read-only and no host SSH keys. If the agent must write, give it a scratch copy of the tree.
- Short-lived, scoped credentials. Short-lived tokens per job instead of long-lived personal access tokens. If a token cannot be exfiltrated usefully, an RCE becomes an inconvenience instead of an incident.
- Restrict egress. Most exfiltration needs outbound network access. An allowlist turns a large share of attacks into failed tool calls.
- Turn off auto-run. Require approval for shell commands, package installs and network calls. It costs a few clicks a day and buys back the last human checkpoint.
- Treat rules files as code.
CLAUDE.md,.cursor/rules,AGENTS.md,copilot-instructions.md— review them in pull requests like any other executable input. - Pin and audit MCP servers. Every tool description is untrusted text that lands in the context window; version-pin them and treat updates as a change request.
- Separate identities per agent so logs actually tell you what happened, and keep a patch cadence that covers the agent tooling itself, not just your project dependencies.
Is the answer to stop using these tools? No. The productivity gain is real, and in our own workflows it shows up in shipped work rather than in demos. But the honest framing is this: you are running an autonomous process with your credentials, on infrastructure that holds your company’s code. That deserves roughly the same paranoia as exposing a port to the internet — and most teams have not got there yet.
Is this the same thing as prompt injection?
Overlapping, but not identical. Prompt injection is a broader way of getting instructions into an agent. The remote code execution is what happens when those instructions, or a compromised plugin path, reach a tool that can run code. Fully preventing injection across arbitrary contexts is an unsolved research problem; limiting what the tools are allowed to do is not.
If I run the model locally with Ollama, am I safe?
No. The flaw lives in the agent layer — the editor extension, the CLI, the tool-calling loop — not in the model weights. Local inference changes where your data goes and how you pay for it; it does not change what an agent can do once it decides to execute a command.
Should we ban AI coding agents internally?
A ban is usually unenforceable, because developers will use them anyway. Scoping their permissions, containing their runtime and logging their actions gets most of the security benefit without creating a shadow-IT problem.
