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.
At a glance
What this is: This is Exaforce’s incident analysis of the LottieFiles npm compromise, showing how phishing, stolen maintainer credentials, and direct package publication bypassed the normal release pipeline.
Why it matters: It matters because npm trust now depends on identity, provenance, and distribution controls, which are part of the software supply chain governance that IAM and security teams increasingly have to own.
By the numbers:
- LottieFiles estimated the affected lottie-player package reached over 11 million daily active users.
Context
The security gap here is not just malicious code in a popular package. The core failure was trust in the publishing path, where a phished maintainer account could still publish directly to npm and reach downstream consumers before detection and cleanup.
For identity and supply chain teams, this is a governance problem as much as a software problem. Package provenance, maintainer authentication, access revocation, and CDN distribution controls all sit on the same trust chain, and a weak link in any one of them can turn routine package updates into an enterprise exposure.
Key questions
Q: What fails when a package maintainer account is phished?
A: The failure is publisher trust, not just endpoint security. Once a maintainer account is compromised, the attacker can publish malicious updates through a trusted distribution channel and reach downstream builds without exploiting application code directly. That is why package publishing should be governed like a privileged identity path, with strong authentication, narrow roles, and rapid revocation.
Q: Why does package provenance matter after a maintainer compromise?
A: Provenance matters because it separates verified releases from anything a stolen account can push directly to a registry. Without cryptographic proof of origin and build path, teams cannot distinguish approved artifacts from attacker-published ones, especially when the package is distributed automatically through mirrors and CDNs.
Q: What are the signs that package trust controls are too weak?
A: Warning signs include broad use of latest tags, missing provenance requirements, direct CDN loading without integrity checks, and no policy for critical dependency approval. If any of those are true, the organisation is relying on convenience rather than verifiable trust. That usually means malicious updates can move from publish to production with little resistance.
Q: How should teams respond when a vulnerable npm package is reachable in production?
A: Prioritise remediation based on execution path, ownership, and external exposure. If the vulnerable function is callable in a production flow, treat it as an active risk, assign it to the current code owner, and verify whether a patch, upgrade, or compensating control can remove the path before the next release.
Technical breakdown
How phishing translated into npm publishing access
The attack began with credential capture through a phishing email sent to a developer’s private Gmail account that was linked to npm. The attacker harvested both npm credentials and two-factor authentication codes, which meant the account could be used as if it were legitimate. That matters because package registries typically trust authenticated maintainers to publish artifacts, so the control boundary sits around the identity, not the code. Once the maintainer context was compromised, the attacker no longer needed to break the build system to reach the registry.
Practical implication: treat maintainer authentication and account recovery as part of supply chain security, not only as helpdesk issues.
Why direct registry publication bypassed release governance
The malicious versions were published directly to the npm registry, bypassing the normal GitHub Actions deployment pipeline. That means the build and publish controls were not the only trust point; the registry itself also accepted a human-published artifact. In supply chain terms, provenance is only useful when publication is constrained to verified workflows and the registry can distinguish approved automation from interactive human release paths. Without that boundary, an attacker who controls a maintainer account can impersonate the release process and push unsigned or unverified content into circulation.
Practical implication: enforce provenance attestation and make direct human publishing an exception that is tightly governed or eliminated.
How CDN propagation amplified the exposure window
After publication, the compromised package versions spread through major CDNs and reached websites configured to pull the latest library version automatically. This is the distribution side of supply chain risk: once a package is accepted upstream, caching, mirroring, and auto-update behaviour can multiply impact far beyond the original registry event. In practice, package trust is no longer limited to the registry and source repository. It includes how downstream consumers resolve versions, how quickly bad artifacts can be purged, and whether distribution layers preserve the ability to revoke or quarantine a release.
Practical implication: inventory downstream package distribution paths and define how compromised artifacts are removed across registries, mirrors, and CDN caches.
Threat narrative
Attacker objective: The attacker sought to distribute wallet-draining code through a trusted JavaScript package and reach DeFi and Web3 users at scale.
- Entry occurred through a phishing email that targeted a developer account linked to npm and captured both credentials and two-factor authentication codes.
- Credential access enabled the attacker to use the maintainer identity to publish three malicious lottie-player versions directly to the npm registry.
- Impact followed when the compromised versions propagated through CDNs and reached sites configured to automatically consume the latest package release.
Breaches seen in the wild
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
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
Package trust is now an identity governance problem, not just a build integrity problem. The compromise worked because a valid maintainer identity still had the power to publish harmful artifacts after credential theft. That shifts the governance question from code review alone to who can publish, how that identity is proven, and when that privilege is revoked. The practitioner implication is that registry publishing rights need the same lifecycle discipline as any other privileged access.
Provenance attestation only matters when it closes the direct publishing path. Exaforce’s description shows that the normal GitHub Actions release path could be bypassed by a human-published release. That is the failure mode: provenance controls do not protect the supply chain if the registry still accepts out-of-band human publishing from compromised identities. Practitioners need to treat this as a control boundary problem, not a tooling problem.
Ephemeral release trust is the missing concept in package ecosystems. The package was trusted because it was historically associated with a legitimate maintainer and a familiar release process, but that trust was not conditioned on verified workflow execution at publish time. Once a maintainer identity is compromised, inherited trust can outlive the identity owner’s intent. The implication is that package ecosystems need stronger issuance-time verification, not just after-the-fact detection.
CDN distribution turns a single registry compromise into a wider trust collapse. The article shows that the malicious versions spread beyond the registry into downstream delivery paths, which means package governance cannot stop at the upstream source. This widens the operational question to distribution revocation, cache invalidation, and consumer version pinning. Practitioners should treat downstream distribution as part of the control plane.
The security model for open-source package ecosystems assumes too much about maintainer behaviour. The incident demonstrates that access to publish is still often granted as a durable privilege, even though the real risk is transient compromise through phishing. That assumption breaks because publisher identity is not the same as publisher intent. The practitioner implication is that publishing authority must be constrained by workflow, not just by account state.
From our research library:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
- Read next: Ultimate Guide to NHIs — Key Challenges and Risks
What this signals
Ephemeral credential trust debt: package ecosystems still behave as if publisher identity remains stable long enough to be trusted across the whole release chain, but phishing collapses that assumption in minutes. Governance now has to verify issuance at publish time, not only inspect code after the fact.
The broader signal is that software supply chain security is converging with identity governance. Maintainer accounts, release automation, and downstream distribution paths all need lifecycle control, because a compromised publisher can still turn routine package updates into enterprise-wide exposure.
For practitioners
- Enforce provenance attestation for package publishing Require cryptographic attestation that every release was built and published through a verified workflow, and block direct human publication to the registry.
- Harden maintainer account recovery Treat registry maintainer accounts as privileged identities with phishing-resistant authentication, strong recovery controls, and rapid revocation paths after compromise.
- Audit downstream package distribution paths Map registries, mirrors, and CDNs that can continue serving compromised artifacts, then define how you will invalidate cached packages and force clean versions.
- Restrict release authority to approved automation Remove ad hoc human publishing from normal package release flow so that only approved CI/CD automation can create production artifacts.
Key takeaways
- The compromise shows that package trust can fail at the identity layer even when code and build processes appear normal.
- Exaforce says the affected lottie-player package reached over 11 million daily active users, which shows how quickly a registry compromise can scale.
- The most relevant control lesson is to combine provenance attestation with strict publishing restrictions and downstream revocation capability.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | A compromised maintainer account let an external actor publish malicious package versions. |
| NHI-04 — Insecure Authentication | Phishing captured registry credentials and 2FA codes, enabling account misuse. | |
| NHI-10 — Human Use of NHI | A human maintainer account was used as the control point for package publication. | |
| Recommendation — Inventory third-party maintainer identities and restrict their publish paths to verified workflows. Harden registry authentication and recovery so maintainer access cannot be replayed after phishing. Separate human identity actions from automated release authority and require workflow-bound publishing. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack used phishing for credential access and then moved into package distribution. |
| Recommendation — Map maintainer compromise to credential access and distribution abuse in your detection and response plans. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Registry publishing permissions and downstream distribution rights were central to the compromise. |
| Recommendation — Review publishing entitlements and remove direct release paths that exceed intended access. | ||
Key terms
- Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
- Registry publishing authority: Registry publishing authority is the right to create or replace a package in a software registry. It is a privileged identity function, not a routine developer action, because anyone holding it can affect downstream consumers at scale if the account is compromised.
- Downstream distribution layer: A downstream distribution layer is any cache, mirror, CDN, or delivery path that serves a package after it leaves the source registry. These layers can extend the life of a malicious artifact even after the original publish point has been remediated.
- Ephemeral Credential Trust Debt: Ephemeral credential trust debt is the hidden risk that appears when short-lived tokens create a false sense of safety while permissions remain broad. The credential expires quickly, but the underlying blast radius stays large unless identity scope, revocation, and audit controls are also tightened.
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 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org