What Happened
SafeDep discovered 36 malicious npm packages posing as legitimate Strapi CMS plugins. These packages exploited Redis and PostgreSQL connections to deploy reverse shells and steal credentials from development environments. Four sock puppet accounts uploaded these packages to npm over a 13-hour period, embedding malicious payloads in postinstall script hooks that executed automatically during npm install—no user interaction needed.
The attack targeted developers using Strapi CMS, a popular open-source headless CMS. Once installed, the packages connected to attacker-controlled infrastructure, established persistent backdoors, and exfiltrated environment variables containing database credentials and API keys.
Timeline
The attack unfolded with precision:
- T+0 hours: First sock puppet account created on npm
- T+0 to T+13 hours: Four accounts uploaded 36 packages with names similar to legitimate Strapi plugins
- T+13 hours: Upload activity stopped
- Post-installation: Malicious code executed within postinstall hooks during package installation
- Detection: SafeDep identified the packages through automated supply chain monitoring
The 13-hour upload window indicates a deliberate campaign, not opportunistic exploitation. The attackers understood npm's trust model and the automatic execution of lifecycle scripts.
Which Controls Failed or Were Missing
Dependency verification controls: Your team may run npm install without verifying package authenticity. No signature checking, hash validation, or publisher verification. The npm ecosystem doesn't enforce package signing by default, and many teams lack additional verification layers.
Postinstall script review: The malicious code resided in postinstall hooks—lifecycle scripts that npm executes automatically. If you're not auditing these scripts before installation, you're allowing arbitrary code to run with full privileges in your development environment.
Least privilege for development environments: The packages exploited Redis and PostgreSQL connections, indicating your development environments likely have direct database access with credentials stored in environment variables. Consider network segmentation, credential rotation, and just-in-time access.
Supply chain monitoring: The packages remained available until SafeDep's discovery. Without monitoring dependencies for suspicious patterns—rapid uploads, new publishers, typosquatting names—you're operating blindly.
Credential exposure in environment variables: The attack harvested credentials from environment variables. Your .env files and shell environments contain production-level secrets accessible to any process in your development environment.
What the Relevant Standards Require
OWASP ASVS v4.0.3 Requirement 14.2.1 mandates that all components, including libraries and frameworks, come from trusted sources over secure channels. Running npm install against unverified packages violates this control. Implement a process to verify package publishers and review changes before installation.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires integrity verification mechanisms for software components. For npm packages, this means implementing hash verification, using lock files, and maintaining an approved package allowlist.
PCI DSS v4.0.1 Requirement 6.3.2 states that custom software is developed securely, including the security of third-party components. If a malicious npm package deploys a reverse shell into your development environment, you've created a direct path from the internet to systems handling cardholder data.
ISO/IEC 27001 Control 8.30 (Outsourced Development) requires security controls for externally developed software. Open-source packages are externally developed software. Document procedures for vetting, approving, and monitoring these dependencies.
SOC 2 Type II CC6.8 requires monitoring of system components to detect anomalies. Thirty-six packages uploaded in 13 hours by new accounts is an anomaly your supply chain monitoring should catch.
Lessons and Action Items for Your Team
Implement package verification before installation. Use npm audit signatures when available, or create your own verification layer. For critical projects, pin exact versions in package-lock.json and review all version updates through pull requests. Never run npm install on a new package without reviewing its postinstall scripts first.
Disable automatic script execution in CI/CD. Set ignore-scripts=true in your .npmrc file for build environments. This may break some legitimate packages, but it helps identify which packages require script execution for auditing.
Rotate credentials that lived in compromised environments. If you installed any package during this attack window, assume your environment variables were exfiltrated. Rotate every credential, API key, and database password that existed in those environments, including those in .env files, shell history, and process memory.
Segment development environment access. Developers don't need direct production database access. Implement database proxies, use read replicas for development, and require VPN or bastion hosts for any production system access. A reverse shell on a developer's laptop shouldn't provide a direct path to your production Redis instance.
Build supply chain monitoring into your security program. Use tools like Socket, Snyk, or SafeDep to monitor new package publications in your dependency tree. Alert on new publishers, rapid version increments, and packages with names similar to your existing dependencies. This is a detective control—it won't prevent installation, but it shortens your exposure window.
Audit your existing dependencies for postinstall scripts. Run npm ls --parseable | xargs -I {} cat {}/package.json | grep -A 5 postinstall to identify every package in your tree that executes code during installation. Review each one. If you can't explain why it needs postinstall execution, find an alternative package.
Document your package approval process. Create a runbook for adding new dependencies: who approves them, what checks run, how you verify publisher identity. This becomes your evidence for ISO/IEC 27001 Control 8.30 and your documented procedure for PCI DSS Requirement 6.3.2.
The npm ecosystem's trust model assumes package publishers are benign. Your security model cannot.
