TL;DR: A compromised maintainer account was used to publish a self-propagating npm worm across 11 malicious releases, with hundreds more republished within hours and persistence planted so a repository opening could trigger compromise without npm install, according to Cycode. The incident shows that provenance, package signing, and install-script controls do not fully address AI coding agent and IDE execution paths, so trust assumptions now need to cover repository-open behaviour, not just dependency installation.
At a glance
What this is: Cycode analyses an npm worm that used a compromised maintainer account, signed releases, and AI coding agent and IDE persistence to spread without requiring npm install.
Why it matters: It matters because identity and supply-chain controls that focus only on package provenance and install scripts do not cover repository-open execution paths now used by developer tools and coding agents.
Context
This article is about a supply-chain compromise that turned a trusted maintainer identity into a delivery mechanism for malicious npm releases. The key governance gap is not merely package provenance, but the fact that developer workflows and AI coding agents can execute repository content before a traditional install path is ever reached.
For IAM and NHI programmes, the important shift is that the trust boundary now extends into IDE configuration, agent startup behaviour, and token-bearing developer environments. A package can be signed and still be weaponised through adjacent execution paths that existing review and dependency controls do not observe.
The incident is a strong example of why non-human identity governance must include build systems, developer tooling, and agent-triggered execution, not just registry and repository hygiene.
Key questions
Q: What breaks when AI coding agents automatically install poisoned npm packages?
A: The break point is the human review window. When an agent resolves and installs dependencies on its own, a malicious package can execute before anyone checks the version, the maintainer, or the code path. That turns package trust into a runtime governance issue and increases the chance that secrets, tokens, and workflow permissions are exposed during normal delivery.
Q: Why do signed npm releases still create supply-chain risk?
A: A valid signature only proves the artefact came through the expected pipeline. If the maintainer account or release workflow is compromised, the signature can faithfully attest to malicious content. Teams should therefore combine provenance checks with account-integrity monitoring and runtime detection, not treat signing as a complete trust decision.
Q: What are the signs that repository-open persistence is active in developer tools?
A: Look for unexpected commands in IDE settings, agent task files, or workspace configuration that launch scripts when a folder opens. Also watch for unusual outbound traffic, credential access, or new background processes after a repository is opened, even when no install event occurred.
Q: How should teams contain a worm that can trigger token revocation logic?
A: Containment has to start by removing the persistence and kill-switch logic before rotating exposed credentials. If revocation is the trigger, blind rotation can activate the attacker’s final stage. Rebuild affected hosts, clean both IDE-trigger paths, and then rotate credentials from a known-good environment.
Technical breakdown
Why provenance-signed releases can still be malicious
Package provenance proves that a build came from a legitimate pipeline, not that the source repository or maintainer account was uncompromised. In this incident, the attacker used the maintainer’s GitHub identity to publish through the normal release path, so the attestation was technically valid while the content was hostile. That is a supply-chain trust problem, not a signature problem. Signed artefacts reduce ambiguity about origin, but they do not authenticate intent, operator control, or post-publish behaviour. When the maintainer identity is abused, provenance becomes evidence of a compromised workflow rather than a control that prevents compromise. Practical implication: treat provenance as one signal, not a stand-alone trust decision.
Practical implication: verify signed releases against source-control and account-integrity signals, not attestation alone.
How AI coding agents become an execution path
The novelty here is that the malware did not rely only on npm install. It planted cross-wired hooks in .claude/settings.json and .vscode/tasks.json so opening the repository or starting an AI coding session could execute the payload. That changes the identity problem from package trust to runtime trust in developer tooling. The actor is no longer just a package consumer; it is an environment that can autonomously or semi-autonomously load repository instructions and trigger code. For governance, this is a boundary break between source code, IDE state, and agent behaviour. Practical implication: repository-open events and agent startup must be treated as security-relevant execution moments.
Practical implication: monitor repository-open and agent-start events as security-relevant execution points.
Why install-script controls do not close the gap
Disabling install scripts reduces one execution route, but this worm used multiple paths. One path ran through preinstall behaviour, while other triggers lived in IDE and agent configuration that never touched node_modules at all. That means a package policy focused only on npm install, npm ci, or --ignore-scripts leaves a blind spot where the code still executes from the developer environment itself. The security lesson is that build and workstation controls must account for configuration-driven execution, not just dependency installation. Practical implication: separate package execution controls from IDE and agent configuration controls, because they fail independently.
Practical implication: do not assume ignore-scripts or lockfile controls protect IDE and agent-triggered execution.
Threat narrative
Attacker objective: The attacker sought to turn trusted package distribution and developer tooling into a repeatable path for stealing credentials, spreading the worm, and maintaining control over compromised environments.
- Entry occurred when the attacker used a compromised maintainer GitHub identity to publish malicious npm releases through a trusted workflow.
- Credential-bearing persistence was planted in AI agent and IDE configuration so repository opening could execute code without an explicit npm install.
- The payload stole tokens and secrets, resolved command-and-control dynamically, and used exfiltration plus revocation logic to preserve access while spreading further.
- Impact included credential theft, repository contamination, and the risk of downstream compromise across developer workstations, CI, and build systems.
Breaches seen in the wild
- Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).
- Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Repository-open trust is now part of the identity perimeter: This campaign shows that package trust is no longer limited to install-time execution. The same repository can execute code through IDE and agent configuration before any package manager event occurs, which means the governance boundary has expanded into developer tooling and agent startup. Security teams need to treat repository-open behaviour as an identity-bearing execution path, not a neutral file-system action.
Provenance can attest to a compromised workflow: Valid signatures did not prevent malicious content because the maintainer account and release pipeline were already under attacker control. That breaks the assumption that attestation alone establishes trust in the artefact. The practical conclusion is that provenance must be interpreted alongside account integrity, release timing, and behaviour at runtime.
Agentic execution changes the trust model for non-human identities: AI coding agents do not merely consume packages; they can be induced to act on repository state and configuration. That means least privilege, review cadence, and change-control assumptions built for deterministic software installation are insufficient when execution is triggered by a tool that interprets its environment. The governance model must account for tool-initiated action, not only human-initiated installs.
Credential theft is now coupled to persistence logic: The payload’s revocation-triggered behaviour means reactive rotation can become the trigger for the attacker’s fallback path. That is a control inversion, where a defender action activates the malware’s last stage. Practitioners should recognise this as a lifecycle problem in which revocation and cleanup sequencing matter as much as discovery.
Identity blast radius is determined by developer trust chains, not package count alone: The worm spread through explicit installs, patch-range republishing, and seeded repository execution. The named concept here is identity blast radius, meaning the distance a trusted identity can project compromise through adjacent tooling and workflow trust. The relevant question is not how many packages were touched, but how many execution surfaces trusted the same identity state.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Repository-open execution expands the control boundary: Teams that only govern install-time package risk will miss the execution paths now living in IDE and agent configuration. That changes the programme question from “what dependencies are trusted?” to “what workspace events can trigger code?” and it makes developer-tool settings part of security governance, not local convenience.
Identity blast radius is the better metric here than package count: A trusted maintainer identity can project compromise through signed releases, patch-range republishing, and repository-triggered execution. The operational signal is not just how many packages were touched, but how many execution surfaces accepted the same trust state before review.
According to the State of Secrets Sprawl 2026, Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025.
For practitioners
- Audit repository-open execution paths Review .claude, .vscode, and other developer-tool configuration files for commands that execute when a repository is merely opened. Treat those files as part of the trusted execution surface, not just workspace preferences.
- Separate install controls from agent controls Keep npm install hardening in place, but add controls for IDE launch events, agent startup hooks, and workspace auto-execution. Ignore-scripts does not stop configuration-driven payloads.
- Rebuild hosts that touched seeded repos Assume any workstation or CI runner that installed an affected package or opened a seeded repository is compromised. Rebuild before rotating credentials so persistence and kill-switch logic are removed first.
- Constrain release-age risk in CI Add a release-age cooldown and require verified version allowlists for newly published dependencies. Patch-range republishing is how worm activity silently reaches systems already carrying caret ranges.
- Monitor agent and build runtime behaviour Watch for unexpected Bun execution, Ethereum RPC calls, token access, and repo-creating behaviour from build agents or developer workstations. These are behavioural signals, not provenance signals.
Key takeaways
- This worm worked because trusted maintainer identity, signed releases, and developer-tool execution were chained together into one delivery path.
- The incident demonstrates that repository-open behaviour and AI coding agent startup can be security-relevant even when npm install never happens.
- Containment depends on removing persistence and kill-switch logic before rotating credentials, or the defender action can become the attacker trigger.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The worm steals tokens and secrets from developer and CI environments. |
| NHI-03 — Vulnerable Third-Party NHI | A compromised maintainer account became the delivery path for malicious releases. | |
| NHI-07 — Long-Lived Secrets | Revocation timing and broad token reuse amplify the blast radius of stolen credentials. | |
| Recommendation — Scan developer and CI surfaces for leaked secrets and revoke exposed credentials immediately. Verify third-party maintainer trust and remove package dependencies tied to compromised identities. Shorten secret lifetime and separate revocation steps from credential replacement workflows. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The malware abuses agent and developer-tool identity pathways to execute and spread. |
| Recommendation — Restrict agent and workspace privileges so repository state cannot trigger unrestricted execution. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Stolen tokens and revocation sequencing make authenticator lifecycle central to containment. |
| Recommendation — Apply IA-5 to inventory, revoke, and reissue exposed authenticators in a controlled sequence. | ||
| MITRE ATT&CK | TA0006;TA0011;TA0040 — Credential Access; Command and Control; Impact | The worm harvests credentials, resolves C2 dynamically, and creates downstream compromise. |
| Recommendation — Map telemetry to credential access, command-and-control, and impact stages to prioritise containment. | ||
Key terms
- Repository-open execution risk: The condition where simply opening a repository can trigger code, scripts, or agent actions without a package install. It matters because editor settings, workspace files, and AI assistant configuration can become execution surfaces that bypass traditional dependency controls.
- Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Workspace Trust: A trust control in code editors that separates passive file viewing from active execution of project-defined tasks. When disabled or bypassed, the editor can run repository instructions in the user’s context, which turns source control content into an execution path.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org