Notifications
Clear all
Topic starter
18/08/2026 2:32 pm
TL;DR: Npm supply chain attacks increasingly begin with stolen maintainer credentials, publishing tokens, or CI/CD identities, and Xygeni says the largest wave in the registry’s history included the chalk/debug hijack, the Shai-Hulud worm, and nation-state malware hidden in a package downloaded 100 million times a week. The control gap is now publication-time identity abuse, not just code scanning after release.
NHIMG editorial — based on content published by Xygeni: npm supply chain attacks and compromised identities in the 2025 to 2026 wave
Questions worth separating out
Q: What breaks when npm publishing identities are not tightly controlled?
A: Attackers can use a stolen maintainer account or CI/CD token to publish malicious packages that look legitimate to developers and automation.
Q: Why do npm supply chain attacks remain effective even when teams scan dependencies?
A: Dependency scanning is usually post hoc, while these attacks often execute at publish time or install time.
Q: What do security teams get wrong about token rotation in CI pipelines?
A: They often treat rotation as equivalent to removal.
Practitioner guidance
- Lock down package publishing identities Require hardware-backed MFA, narrow token scope, and explicit ownership for npm publishing accounts, CI/CD tokens, and runner credentials.
- Block install-time script execution by default Disable or sandbox postinstall and other install scripts for packages that do not genuinely need runtime code execution during installation.
- Monitor for publish-after-publish propagation Watch for repeated releases, unusual namespace changes, and unlock-inject-relock patterns that indicate a stolen identity is being used to spread malicious packages.
What's in the full article
Xygeni's full post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step breakdown of the unlock-inject-relock CI/CD compromise pattern seen in recent npm incidents.
- Behavioral indicators for detecting malicious package publication before install time.
- Detailed comparison of malware early warning and dependency firewall controls across npm, PyPI, Maven, NuGet, and RubyGems.
- Remediation workflow examples for handling compromised publishing identities and poisoned package versions.
👉 Read Xygeni's analysis of npm supply chain attacks and compromised identities →
Npm supply chain attacks: what identity teams need to know?
Explore further
18/08/2026 3:19 pm
Identity compromise is now the primary supply chain control failure in npm abuse. The article shows that attackers do not need to break npm itself if they can borrow a maintainer’s key to the registry. That shifts the governance problem toward publishing identities, CI/CD tokens, and secrets hygiene across the software delivery chain. Practitioners should treat package publishing as a privileged action with explicit lifecycle control.
A question worth separating out:
Q: Who should be accountable when compromised npm packages spread through CI and developer systems?
A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.
👉 Read our full editorial: Npm supply chain attacks now exploit identity, not code
