On October 30, 2024, between 8:12 PM and 9:57 PM GMT, an attacker with control of a compromised npm publishing token pushed three malicious versions — 2.0.5, 2.0.6, and 2.0.7 — of @lottiefiles/lottie-player to the npm registry. The package, a widely embedded web component for rendering Lottie animations, counts more than 4 million lifetime installs and roughly 94,000 weekly downloads. Within hours, websites and applications pulling the "latest" build from npm or from unpinned CDN links began silently serving a cryptocurrency wallet drainer to their own visitors. LottieFiles confirmed the compromise publicly on October 31, pulled the malicious releases, and shipped a clean version, 2.0.8, built from the last known-good release, 2.0.4. At least one reported victim lost approximately 10 BTC — roughly $723,000 at the time — after connecting a wallet through the injected prompt.
The incident is a clean, well-documented case study in a pattern security teams have seen accelerate since 2022: attackers no longer need to break into a company's network when they can compromise a single developer's publishing credentials and let the software supply chain do the distribution for them.
Timeline of the Compromise
- October 30, ~8:12 PM GMT — Version 2.0.5 of
@lottiefiles/lottie-playeris published to npm containing injected malicious code. - October 30, ~9:57 PM GMT — Versions 2.0.6 and 2.0.7 follow, apparently as the attacker iterated on the payload or reacted to early detection attempts.
- October 30–31 — Sites and applications loading the package from npm registries or from CDNs (unpkg, jsDelivr) without a pinned version begin serving the tainted build to end users as the automatic "latest."
- October 31 — Community members and researchers flag anomalous wallet-connection pop-ups appearing on unrelated sites; LottieFiles opens a public GitHub issue and begins investigating.
- October 31 (same day) — LottieFiles confirms the account takeover, revokes the compromised token, removes 2.0.5–2.0.7 from the registry, and publishes 2.0.8, a re-release of the verified-clean 2.0.4 codebase.
The company's response window — from public disclosure to a validated fix — was measured in hours, not days, which limited the blast radius relative to comparable incidents. But "hours" is still more than enough time for an unpinned CDN dependency to reach production on thousands of downstream sites.
Anatomy of the Attack
The root cause was not a vulnerability in lottie-player's code — it was a compromised human. Investigators traced the takeover to a phishing email that harvested credentials or a session/access token from a LottieFiles developer with publish rights on the npm package. Once in possession of that token, the attacker didn't need to submit a pull request, pass code review, or touch the GitHub repository at all. npm's publish flow allows a valid token holder to push a new version directly to the registry, bypassing the same source-control safeguards that would normally have flagged the change.
The payload itself was purpose-built for cryptocurrency theft rather than generic data exfiltration. The injected code bundled UI and integration logic lifted from official wallet SDKs, engineered to render a convincing "Connect Wallet" prompt on any page that loaded the animation library. Because lottie-player is typically embedded for cosmetic purposes — loading screens, onboarding animations, marketing sites — most site operators had no reason to expect it could request wallet permissions, and most end users had no reason to distrust a prompt appearing on a site they already trusted. Once a user approved the connection, the drainer logic attempted to move funds out of the connected wallet.
This is functionally identical in spirit to the polyfill.io CDN hijack earlier in 2024 and echoes the mechanics of event-stream (2018), ua-parser-js (2021), and coa/rc (2021): a trusted, transitively-included package becomes the delivery mechanism, and the compromise rides in on legitimate update channels that most build pipelines are configured to trust by default.
Why It Spread So Fast
Three structural factors amplified the impact well beyond LottieFiles' own userbase:
Unpinned CDN and registry references. A significant share of lottie-player's real-world usage comes not from an npm install captured in a lockfile, but from <script> tags pointing at unpkg or jsDelivr URLs referencing @latest or an unpinned major/minor version. Every one of those sites auto-upgraded to the malicious build the moment it was published — no npm install, no CI run, no code review required on the consuming side.
A component with a benign reputation. Animation libraries sit low on most organizations' risk radar. Lottie-player would rarely, if ever, appear on a short list of dependencies subjected to extra scrutiny, precisely because its function — rendering vector animations — has no obvious reason to touch wallets, cookies, or authentication flows. Attackers increasingly favor exactly this kind of "boring" dependency because it inherits trust it never earned through security review.
Publish-time trust, not merge-time trust. Because the compromise happened at the npm publish step rather than in the GitHub repository, none of the usual code-review, branch-protection, or CI-gating controls that LottieFiles or its downstream consumers had in place ever had a chance to catch it. The malicious diff never appeared in a pull request; it appeared only in the published tarball.
What This Incident Confirms About the Threat Landscape
Lottie-player joins a growing 2024 ledger of maintainer-account compromises — alongside incidents affecting packages tied to crypto tooling, build utilities, and now UI libraries — that share a common shape: phishing or credential theft targeting an individual maintainer, followed by a direct-to-registry publish that skips source control entirely. For defenders, this shifts the relevant question from "did we review this code" to "do we even know this code changed underneath us."
It also underscores a widening gap between how organizations track first-party dependencies (via lockfiles and SBOMs) and how browsers actually load them in practice (via CDN script tags that ignore lockfiles entirely). Any inventory of exposure that stops at package-lock.json will miss the CDN-sourced copies that were, in this case, the primary infection vector.
How Safeguard Helps
Incidents like the lottie-player compromise are why Safeguard treats dependency risk as a continuous, reachability-aware problem rather than a point-in-time scan. Griffin AI continuously monitors package registries and changelogs for anomalous publish activity — such as a version jump with no corresponding commit history or code review trail — and flags it before teams unknowingly pull it into a build. Safeguard's reachability analysis determines whether a flagged package like lottie-player is actually invoked in a way that could execute the malicious code path in your specific application, cutting through alert noise so teams can prioritize the handful of deployments genuinely at risk rather than every repository that merely lists the dependency. Automated SBOM generation and ingest give security teams a live, queryable record of every version of every dependency in use — including CDN-sourced and transitive packages that traditional lockfile audits miss — so that when an advisory like this one drops, the question "are we exposed, and where" can be answered in minutes instead of days. When exposure is confirmed, Safeguard can open auto-fix pull requests that pin affected packages to a verified-safe version across every impacted repository simultaneously, closing the same unpinned-CDN gap that let this attack spread. Together, these capabilities are designed to compress the gap between disclosure and remediation from the industry's typical days-to-weeks down to the same hours-long window LottieFiles itself achieved — but without requiring every downstream consumer to be watching npm advisories in real time.