Between late 2024 and early 2025, four malicious npm packages delivered the Shai-Hulud infostealer to developer machines. These packages—typosquats of legitimate tools—were downloaded 2,678 times before their removal. This was not sophisticated nation-state tradecraft but rather leaked malware from the TeamPCP hacker group, now available to anyone who can write a package.json file.
What Happened
OXsecurity researchers identified four npm packages containing the Shai-Udluh variant of Shai-Hulud malware. These packages used typosquatting—deliberate misspellings of popular package names—to deceive developers during installation. Once executed, the malware exfiltrated credentials, browser data, and system information to a command-and-control server at 87e0bbc636999b[.]lhr[.]life. One variant also included DDoS capabilities.
The attack exploited the trust model of package managers: developers assume packages with plausible names are legitimate, and npm executes installation scripts automatically by default.
Timeline
- Pre-incident: TeamPCP's original Shai-Hulud malware leaked, lowering the barrier for copycat attacks.
- Late 2024: First malicious packages published to npm registry.
- Early 2025: OXsecurity detection systems flagged suspicious packages during automated scanning.
- January 2025: Packages removed from npm after researcher disclosure.
- Post-removal: Unknown number of compromised developer machines remain infected; credential theft impact ongoing.
The gap between publication and detection represents the window where your CI/CD pipeline could have pulled a compromised package into production builds.
Which Controls Failed or Were Missing
Dependency Verification: No cryptographic signature validation for packages. npm's model trusts package names and maintainer accounts, not package contents. If a typosquatted package name passes your team's visual review, it installs.
Installation Script Sandboxing: npm executes pre-install and post-install scripts with the full permissions of the installing user. The malware ran immediately during npm install, before any application code executed. No approval prompt, no restricted environment.
Egress Filtering: The malware successfully connected to its C2 server from developer workstations. Your network allowed arbitrary outbound connections from machines with access to production credentials, source code repositories, and cloud provider keys.
Automated Dependency Scanning: The 2,678 downloads suggest many organizations lacked real-time package reputation checks. If your CI/CD pipeline pulls packages without scanning them against threat intelligence feeds, you're installing blindly.
Credential Isolation: Developers had browser sessions, SSH keys, AWS credentials, and other secrets accessible to any process running in their user context. When the malware enumerated the filesystem, it found everything.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2: "An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained." You need a software bill of materials (SBOM) that includes every npm package. When a malicious package is disclosed, you must know within minutes whether you're affected.
Requirement 6.2.4: "Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities." This includes supply chain attacks. Typosquatting isn't a novel technique—your secure development lifecycle should address it.
NIST 800-53 Rev 5 SR-3 (Supply Chain Controls and Processes): Requires organizations to employ "anti-counterfeit technologies" and "inspection of information systems, system components, or information system services." For npm packages, this means automated verification that packages match expected checksums and originate from trusted publishers.
SR-4 (Provenance): "Document, monitor, and maintain valid provenance of systems, system components, and associated data." Every package in your dependency tree needs provenance tracking. When npm install pulls 300 transitive dependencies, you should know where each one came from.
ISO 27001 Annex A.8.30 (Outsourced Development): Requires supervision and monitoring of outsourced system development. Open-source packages are outsourced development. You're running code written by strangers—treat it accordingly.
OWASP Top 10 2021 A06:2021 – Vulnerable and Outdated Components: Explicitly calls out the risk of using components from untrusted sources or without verifying integrity. Typosquatted packages are the textbook example.
Lessons and Action Items for Your Team
Implement Package Signature Verification Now: Tools like Sigstore and npm's upcoming package provenance features let you verify that packages come from their claimed publishers. Configure your CI/CD to reject unsigned packages. Yes, this will break some builds. Fix those builds.
Enable Dependency Review in Pull Requests: GitHub, GitLab, and Bitbucket all offer automated dependency scanning. When a PR adds a new package, the review should flag newly-added dependencies, packages with low download counts, recently-published versions, and names similar to popular packages. A human should approve every new dependency.
Lock Your Dependencies with Checksums: Use package-lock.json or npm-shrinkwrap.json and commit them. When you install packages, npm should verify that the downloaded code matches the recorded checksum. If the package content changes—even with the same version number—the installation fails.
Sandbox Installation Scripts: Run npm install with --ignore-scripts by default. For packages that legitimately need installation scripts (like node-gyp for native modules), audit those scripts before allowing them. Better: run installations in containers with no network access and no credentials mounted.
Restrict Developer Machine Network Access: Your developers don't need direct internet access from their workstations. Route traffic through an egress proxy that blocks connections to unknown domains. When malware tries to phone home to 87e0bbc636999b[.]lhr[.]life, the connection fails.
Separate Credential Storage from Development Environments: Developers should not have AWS keys, database passwords, or API tokens stored in environment variables or dotfiles on their laptops. Use credential vaulting (1Password, HashiCorp Vault) with short-lived tokens. When malware scrapes the filesystem, it finds nothing.
Audit Your Current Dependencies Immediately: Run npm list against the four known malicious package names. Check your CI/CD logs for installations between late 2024 and early 2025. If you find matches, assume credential compromise: rotate every secret those machines could access, review access logs for suspicious activity, and re-image the affected systems.
Subscribe to npm Security Advisories: OXsecurity, Sonatype, and Socket publish real-time feeds of malicious packages. Integrate these feeds into your CI/CD pipeline. When a new threat drops, your builds should fail automatically if they reference it.
The Shai-Hulud campaign succeeded because it required no novel techniques—just leaked malware and a package.json file. Your defense needs to be equally straightforward: verify what you install, limit what it can access, and detect when it misbehaves. The controls exist. Implement them before the next 2,678 downloads include yours.
