A coding agent can look normal while a backdoored extension steals credentials
CERT-EU modified two legitimate packages in an isolated lab. A routine phrase triggered background data collection outside the model's visible tool calls, showing why plugin controls must cover the whole agent environment.
The short version
- What happened
- CERT-EU added trigger-gated collection code to local copies of two legitimate third-party packages used with Pi 1.3.0 and Claude Code 2.1.304; no public package was modified.
- Who it affects
- Developers and organisations can expose source code, tokens and internal services to agent extensions that inherit the user's permissions. The immediate response is inventory and isolation, not panic about a verified breach.
- What remains unproven
- Official two-package laboratory demonstration, not peer-reviewed and not an estimate of malicious-package prevalence.
Keep in mind
Official two-package laboratory demonstration, not peer-reviewed and not an estimate of malicious-package prevalence.
Only Pi 1.3.0 and Claude Code 2.1.304 were tested with locally modified packages and a predefined trigger.
No public package was changed, no real credentials were used and no active exploitation or victim was identified.
Controls and extension architectures differ across agent products; organisations must test their own environment.
Source analysis · 1 linked source. Primary analysed source date: 30 October 2026.
Read the full report · 3 min The evidence, methods, implications and limitations
The payload ran beside the model
A coding agent's visible approvals did not stop malicious code loaded as an extension in a CERT-EU laboratory test. Researchers inserted a small trigger-gated payload into local copies of two legitimate packages, one for Pi 1.3.0 and one for Claude Code 2.1.304. The ordinary phrase “lgtm, ship it” activated both packages, which sent information from the test host to a configured collector while the agents kept responding normally.
The payload used existing event hooks rather than asking the language model to read files or make a network call. In the tested configurations, model tool restrictions therefore did not intercept it. The two transmissions included environment, network, account and credential-related information available to the invoking process. No public package was altered, no real credential was used and no organisation was reported compromised.[1]
Treat extensions as privileged software
For a developer, the practical boundary is the entire agent process, not only the model. CERT-EU recommends running agents in restricted accounts, containers or dedicated virtual machines; exposing only short-lived, narrowly scoped credentials; controlling outbound connections; pinning and reviewing extension versions; and monitoring file access and network behaviour outside model-generated tool calls.
The demonstration used only two modified packages and a chosen trigger, so it does not measure how common malicious extensions are or how often existing controls would detect them. It does show a plausible software-supply-chain route that bypasses a familiar safety assumption. Evidence of a real compromised package, affected users or active exploitation would materially raise the assessment and could justify Breaking treatment.[1]
The distinction that matters
Why a model approval prompt did not help
The malicious action happened in package code already loaded by the agent harness.
Trigger
Routine phrase enters the agent
Extension handler activates
Execution
Package code reads available host data
No model tool call is required
Defence
Restrict process, secrets and network
Controls cover the whole agent environment