On July 19th, 2024, maintainers of eslint-config-prettier discovered their package had been compromised. Attackers published malicious versions containing credential-stealing malware. With 30,000,000 downloads per week, this supply chain incident had massive potential reach.
The attack succeeded through phishing, prompting credential resets and package removal. The real question for your team: which defensive layers failed, and what does your compliance framework require you to have in place?
Timeline
Pre-attack: Attackers registered npnjs.com, a typosquatted version of the legitimate npmjs.com domain, to harvest npm credentials from package maintainers.
Attack execution: Maintainers received phishing messages directing them to the fake domain. At least one maintainer entered credentials on the spoofed site.
Compromise: Using stolen credentials, attackers published malware-infected versions of eslint-config-prettier to the legitimate npm registry.
Detection and response: Community reports led to the detection of the compromise. npm removed the malicious versions and reset affected credentials by July 19th, 9:21 PM UTC+3.
Impact window: The timeline between initial credential theft and detection remains unclear, highlighting a gap in incident response requirements.
Which Controls Failed
Authentication Controls
The compromised account lacked multi-factor authentication (MFA). A phishing-resistant MFA mechanism would have blocked the attack even after credential disclosure. The attacker had a valid username and password — that was enough.
Domain Verification Training
The maintainer didn't recognize npnjs.com as fraudulent. This failure highlights the need for specific anti-phishing controls: browser warnings for typosquatted domains, bookmark-based navigation to critical services, or URL verification procedures for authentication flows.
Publishing Authorization
npm's publishing workflow allowed immediate package updates after authentication, with no secondary approval or anomaly detection. The attacker authenticated and published without friction or review.
Package Signing and Verification
The ecosystem lacks mandatory cryptographic signing for package updates. Users had no mechanism to verify that the new version came from the legitimate maintainer. The npm registry trusted the authenticated session — that trust was misplaced.
What Standards Require
NIST 800-53 Rev 5
IA-2(1) Multi-Factor Authentication to Privileged Accounts requires MFA for accounts with elevated privileges. Publishing to a package with 30 million weekly downloads qualifies as privileged access.
IA-2(2) Multi-Factor Authentication to Non-Privileged Accounts extends this to all remote network access. If your organization uses npm packages in production systems covered by NIST 800-53, you're required to verify that your supply chain dependencies come from MFA-protected accounts.
IA-8 Identification and Authentication (Non-Organizational Users) addresses third-party authentication. When you consume packages from external maintainers, you're trusting their authentication controls. This control requires you to document that trust and verify it meets your security requirements.
ISO/IEC 27001:2022
Annex A 5.15 (Access Control) requires organizations to implement appropriate authentication for access to information and systems. For supply chain dependencies, this means your vendor assessment process must verify authentication controls.
Annex A 5.19 (Information Security in Supplier Relationships) requires you to assess and monitor supplier security practices. If eslint-config-prettier is in your dependency tree, your ISO 27001 implementation should have identified the authentication risk in your supply chain.
Annex A 8.30 (Outsourcing) extends to open-source dependencies. You're outsourcing code execution to external maintainers. The standard requires you to define security requirements for that relationship.
SOC 2 Type II
CC6.1 (Logical and Physical Access Controls) requires the organization to implement controls to prevent unauthorized access. For a SOC 2 audit, your auditor will ask how you verify the security of your software supply chain.
CC6.2 (Authentication) requires multi-factor authentication for systems that process sensitive data. If your application handles customer data and includes npm packages, your control environment includes those packages' authentication mechanisms.
Lessons and Action Items
For Your Development Pipeline
Implement dependency pinning with hash verification. Don't automatically accept new package versions. Your package-lock.json or yarn.lock should pin exact versions with cryptographic hashes. When eslint-config-prettier published malicious versions, teams with hash-pinned dependencies were protected.
Run Software Composition Analysis (SCA) tools in your CI/CD pipeline. Tools like Snyk, Dependabot, or Socket.dev can detect known malicious packages and suspicious version updates. Configure them to block builds on high-severity findings.
Audit your dependency tree quarterly. Run npm ls or yarn why to understand your transitive dependencies. eslint-config-prettier might not be in your package.json, but it could be required by another package you do list. You're responsible for the entire tree.
For Maintainers on Your Team
Enable MFA on all package registry accounts immediately. Use hardware security keys (WebAuthn/FIDO2) rather than TOTP codes. Phishing-resistant MFA prevents credential theft attacks entirely.
Document your publishing workflow. Who can publish? From which machines? What approval process exists? If the answer is "anyone with credentials can publish from anywhere," you have a control gap.
Implement package signing. npm supports package signatures via npm sign. Configure your publishing workflow to sign releases and document the verification process for users.
For Your Vendor Assessment Process
Add authentication requirements to your third-party risk questionnaire. Ask vendors (including open-source maintainers of critical dependencies): Is MFA required? What MFA factors are supported? How are credentials stored and rotated?
Define "critical dependency" thresholds. 30 million weekly downloads is obviously critical. But what's your threshold? Weekly downloads? Privilege level? Access to sensitive data? Document it and apply consistent vendor review.
Create a supply chain incident response plan. When a dependency is compromised, you need a process: How do you detect it? Who decides whether to roll back? How do you verify the integrity of your production deployments? Test this plan — don't wait for an incident to discover your gaps.
The eslint-config-prettier compromise succeeded because multiple defensive layers were missing. Your compliance framework already requires most of these controls. The question is whether you've extended them to your supply chain.
