Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: A phishing-led compromise of a LottieFiles package maintainer enabled malicious npm versions to reach a package with more than 11 million daily active users, and the attack was contained within an hour, according to Exaforce’s incident report. The incident shows that package provenance, maintainer identity, and distribution controls now matter as much as code integrity itself.
NHIMG editorial — based on content published by Exaforce: Exaforce’s response to the LottieFiles npm package compromise
By the numbers:
- The incident was contained within an hour, limiting potential impact on a package with over 11 million daily active users.
Questions worth separating out
Q: How should security teams reduce supply chain risk from compromised package maintainers?
A: Start with maintainer identity assurance.
Q: Why do package publishing workflows create supply chain risk even when code reviews exist?
A: Code review does not stop an attacker who steals publishing credentials and bypasses the normal build path.
Q: What breaks when provenance attestation is not enforced for npm releases?
A: The organisation loses cryptographic proof that a package came from an approved build process.
Practitioner guidance
- Separate maintainer publishing from day-to-day developer access Require distinct accounts, stronger authentication, and narrower scope for package publishing than for routine development activity.
- Enforce provenance attestation for release artifacts Block production distribution unless the package was built through a verified workflow with cryptographic attestation.
- Constrain and log npm access tokens aggressively Use short-lived tokens where possible, scope them tightly, and make revocation immediate across the entire release toolchain.
What's in the full article
Exaforce's full blog covers the operational detail this post intentionally leaves for the source:
- The incident timeline with minute-by-minute detection, deletion, revocation, and CDN purge actions.
- The specific provenance attestation and monitoring measures the team says were introduced after the compromise.
- The detailed account of how maintainer phishing led to malicious publication outside the normal GitHub Actions pipeline.
- The follow-up hardening work around NPM access, developer access revocation, and downstream file removal.
👉 Read Exaforce’s analysis of the LottieFiles npm package compromise →
LottieFiles npm compromise: what it means for package trust controls?
Explore further
02/08/2026 1:02 pm
Package maintainer identity is an NHI governance boundary, not just a developer account. This incident shows that publishing rights, token scope, and recovery speed all matter because the maintainer identity can directly alter production software for millions of users. The governance model has to treat maintainer access like any other high-impact non-human identity with strong lifecycle oversight, revocation, and provenance controls. Practitioners should stop separating software release governance from identity governance.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, according to The State of Secrets in AppSec.
A question worth separating out:
Q: Who is accountable when a stolen maintainer account pushes malicious packages?
A: Accountability sits with both the project maintainers and the organisation operating the publishing identity. Teams should define who owns package release rights, who can revoke them, and how quickly compromised publisher access can be removed. That governance belongs in access review and offboarding processes.
👉 Read our full editorial: LottieFiles npm compromise shows where supply chain trust breaks
