What Happened
Recently, attackers compromised the npm package @lottiefiles/lottie-player, injecting malicious code to steal cryptocurrency wallet credentials. They released three tainted versions—2.0.5, 2.0.6, and 2.0.7—before maintainers detected the breach and issued a clean version 2.0.8.
Before the incident became public, version 2.0.4 (the last safe version) had 36,762 downloads in the preceding week. Within 12 hours of the fix, version 2.0.8 was downloaded 890 times. Applications that automatically updated to the compromised versions risked exposing users to credential theft, as the malicious code targeted cryptocurrency wallets, indicating a focus on high-value targets.
Timeline
The timeline of this incident is not fully clear:
- Unknown date: Attackers gain publish rights for
@lottiefiles/lottie-player - Unknown date: Malicious versions 2.0.5, 2.0.6, and 2.0.7 published
- Detection date unknown: Compromise discovered
- Response: Malicious versions removed from npm
- Response + ~12 hours: Version 2.0.8 released; 890 downloads in first 12 hours
This lack of transparency highlights a common issue: many organizations cannot track when they integrated a compromised dependency or identify affected builds and environments.
Which Controls Failed or Were Missing
Dependency Version Constraints
The main control failure was the automatic acceptance of minor version updates. Teams using version ranges like ^2.0.0 or ~2.0.4 in package.json would have automatically pulled the compromised versions. This is typical in JavaScript dependency management.
Publisher Account Security
Attackers obtained publish rights, suggesting compromised credentials, a compromised CI/CD pipeline, or social engineering. The exact method is unclear, but each scenario indicates a failure in securing the package source.
Build-Time Dependency Verification
Most teams lack controls to detect changes in dependency behavior between versions. Without diffing package contents or running behavioral analysis, such attacks go unnoticed until runtime or external reports.
Runtime Monitoring
Applications using the compromised versions lacked visibility into unauthorized connections or unexpected credential access. Without runtime application self-protection (RASP) or similar monitoring, these activities remained undetected.
What the Relevant Standards Require
OWASP Top 10 2021: A06:2021 – Vulnerable and Outdated Components
OWASP warns against using components with known vulnerabilities or from unmaintained sources. It advises obtaining components from official sources over secure links and preferring signed packages to reduce risks. Continuous monitoring of component security status is essential.
PCI DSS v4.0.1: Requirement 6.3.2
For teams handling payment data, this requirement mandates using software engineering techniques to prevent or mitigate common software attacks. Pulling dependencies without integrity verification or behavioral analysis does not meet this control objective.
NIST Cybersecurity Framework v2.0: ID.SC-4
This framework requires routine assessments of suppliers and third-party partners to ensure they meet contractual obligations. Every dependency update is a new delivery that requires verification.
Lessons and Action Items for Your Team
1. Pin Your Dependencies to Exact Versions
Replace version ranges in package.json with exact versions to ensure every update is deliberate and reviewed:
// Don't do this:
"@lottiefiles/lottie-player": "^2.0.0"
// Do this:
"@lottiefiles/lottie-player": "2.0.4"
2. Implement Dependency Checksum Verification
Use package-lock.json or yarn.lock and commit these files to version control. These lock files include checksums to detect malicious replacements. Configure your CI/CD pipeline to fail builds if checksums don't match.
3. Deploy Automated Vulnerability Scanning
Use tools like Snyk, Socket, or GitHub's Dependabot to detect compromised packages. Ensure they run on every pull request, block merges for high-severity issues, and alert your security team immediately.
4. Audit Your Dependency Update Process
Review who can approve updates and what review they receive. For critical applications, require:
- Security team review for new dependencies
- Automated and manual testing for updates
- Documentation of each dependency's necessity
5. Instrument Runtime Behavior
Deploy monitoring to detect unexpected connections or credential access. Tools with RASP capabilities can alert you to inconsistent behavior. For cryptocurrency functions, allowlist wallet-related API calls and destinations.
The Lottie Player incident highlights the danger of automated processes that deploy code without inspection. Assume compromise is inevitable: pin versions, verify checksums, scan continuously, and monitor runtime behavior. These are essential controls to meet compliance obligations and protect users.
