Notifications
Clear all
Topic starter
19/08/2026 3:39 pm
TL;DR: CanisterWorm shows how a compromised CI/CD toolchain can turn stolen npm publishing tokens into self-propagating malware, with backdoored patch releases spreading across multiple package scopes after Trivy's compromise, according to StepSecurity. The pattern confirms that secret exposure, package trust, and persistence controls now need to be governed as one supply-chain problem.
NHIMG editorial — based on content published by StepSecurity: CanisterWorm, a self-propagating npm worm spreading backdoors across the ecosystem
By the numbers:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
Questions worth separating out
Q: What breaks when npm publishing tokens are stolen from CI/CD environments?
A: When npm publishing tokens are stolen, attackers can impersonate maintainers, publish backdoored versions, and move from one compromised workflow to many affected namespaces.
Q: Why do long-lived registry tokens increase supply chain compromise risk?
A: Long-lived registry tokens increase risk because they remain usable after the original workflow, host, or developer session that created them has changed.
Q: How do security teams know if malicious npm releases have already spread?
A: Teams should compare package release histories, maintainer changes, and install-time scripts across all internal and external dependencies.
Practitioner guidance
- Revoke and rotate all publishing tokens tied to compromised workflows Identify every npm publishing token that existed on any runner, developer device, or workflow that handled the affected packages, then revoke those credentials and issue fresh scoped tokens only after integrity checks are complete.
- Block install-time execution on untrusted dependency updates Flag any newly introduced postinstall script as a security event, and require manual approval or sandboxing before dependency updates can reach production build paths.
- Audit package namespaces for unauthorized republishing Compare release histories across all maintainer-controlled scopes to find unexpected patch bumps, new maintainers, or package versions published from unrecognised IPs or workflows.
What's in the full article
StepSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- Full malicious package fingerprints, including affected npm scopes and version history patterns that help teams verify exposure
- Step-by-step host artifact checks for the Python implant, systemd service, and second-stage drop locations
- The full prevention, detection, and response workflow for npm supply-chain incidents across CI/CD and developer machines
- Package-level examples of how StepSecurity's controls would block cooldown bypass, exfiltration, and malicious republishes
👉 Read StepSecurity's analysis of CanisterWorm and npm token theft →
CanisterWorm and npm token theft: what should teams change now?
Explore further
19/08/2026 4:19 pm
CanisterWorm is a publishing-identity attack, not just malware distribution. The worm works because npm tokens were treated as routine build artefacts rather than governed non-human identities. Once a publishing credential is stolen, package ownership becomes an abuse surface, and the attacker can impersonate the maintainer at ecosystem scale. Practitioner conclusion: registry tokens need the same lifecycle controls as privileged access.
A few things that frame the scale:
- From our research: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
- Our research also shows that internal repositories are 6x more likely to contain secrets than public ones, which reinforces why hidden developer and pipeline locations matter.
A question worth separating out:
Q: Who is accountable when a compromised publish token is used to tamper with packages?
A: Accountability sits with the organisation that allowed a privileged credential to persist beyond the task it served. For IAM and PAM teams, that means the governance question is who owned the token lifecycle, who approved exceptions, and who accepted the blast radius created by standing access.
👉 Read our full editorial: CanisterWorm shows how npm token theft becomes ecosystem spread
