Between August 2025 and now, PhantomRaven published 126 malicious packages to the npm registry. These packages used slopsquatting—intentional misspellings of popular libraries—to trick JavaScript developers into installing them. Once installed, the packages exfiltrated environment variables, SSH keys, AWS credentials, and other sensitive data to attacker-controlled servers. Endor Labs identified the campaign, but 81 of these packages remain available in the npm registry at the time of writing.
Timeline
August 2025: PhantomRaven begins publishing malicious packages to npm using slopsquatting techniques. Packages target common developer tools and libraries with names designed to catch typos during installation.
Campaign progression: The attack evolves to use Remote Dynamic Dependencies (RDD), a technique where malicious code is fetched from external servers at runtime rather than embedded in the package. This allows attackers to evade static analysis and modify behavior after the package passes initial security scans.
Detection: Endor Labs discovers the campaign and reports it. npm removes 45 packages, but 81 remain accessible in the registry.
Current state: Developers who installed affected packages may still have compromised credentials. The RDD technique means some packages could have appeared benign during installation but became malicious later.
Which Controls Failed or Were Missing
Package verification before installation: The affected organizations lacked automated verification of package authenticity. Developers installed packages without checking publisher identity, download counts, or last update dates—all signals that distinguish legitimate packages from slopsquatting attempts.
Dependency pinning: Teams using version ranges (e.g., ^1.2.3) instead of exact versions allowed automatic updates that could pull in malicious packages. Once a typosquatted package entered package.json, subsequent npm install commands propagated it across the team.
Runtime monitoring: No monitoring detected the outbound data exfiltration. The packages sent environment variables and credentials to external servers, but network egress controls didn't flag unexpected destinations from developer workstations.
Supply chain integrity checks: The RDD technique worked because no controls validated that packages only loaded code from their declared dependencies. Packages fetched and executed code from arbitrary URLs at runtime, bypassing any security review of the published package.
Secrets management: Developers stored AWS credentials, SSH keys, and API tokens in environment variables accessible to any Node.js process. The malicious packages read these variables directly—no privilege escalation required.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates that custom software is developed securely, including "software development personnel are trained at least once every 12 months on secure development techniques." This includes supply chain security. Your developers need training on package verification, not just secure coding.
NIST 800-53 Rev 5 control SR-3 (Supply Chain Controls and Processes) requires organizations to "employ [Assignment: organization-defined controls] to protect against supply chain risks to the system, system component, or system service." For npm dependencies, this means technical controls—not just policy—that verify package integrity before installation.
NIST 800-53 Rev 5 control SR-4 (Provenance) requires you to "document, monitor, and maintain valid provenance of organizational systems, system components, and associated data." You need a software bill of materials (SBOM) that tracks every package, its version, and its publisher. Manual package.json files aren't sufficient.
ISO 27001 Annex A.8.30 (Outsourced development) requires security controls when using third-party code. npm packages are outsourced development. You need the same verification processes for an npm package as you'd require for a contractor's code commit.
SOC 2 Type II Common Criteria CC6.6 requires monitoring of system components. If your SOC 2 scope includes development environments, you need monitoring that detects data exfiltration from developer workstations—not just production servers.
Lessons and Action Items for Your Team
Implement package verification gates: Add a pre-commit hook or CI check that fails when package.json includes packages with fewer than 1,000 weekly downloads, packages published in the last 30 days, or packages from unverified publishers. This catches most slopsquatting attempts. Tools like Socket Security and Endor Labs provide this as a service, but you can build basic checks with npm API queries.
Pin exact versions: Change every entry in package.json from ^1.2.3 to 1.2.3. Accept the maintenance burden of manual updates. Version ranges optimize for convenience; exact versions optimize for security. Run npm shrinkwrap to lock transitive dependencies.
Block runtime code loading: Configure your Content Security Policy (CSP) or network egress rules to prevent Node.js processes from fetching code from external URLs during execution. This breaks the RDD technique. Yes, this will break some legitimate packages—that's the point. Evaluate each exception.
Move secrets out of environment variables: Migrate AWS credentials, SSH keys, and API tokens to a secrets manager (AWS Secrets Manager, HashiCorp Vault, 1Password CLI). Configure your applications to fetch secrets on demand with scoped access tokens, not read them from the environment. This limits exposure when a package reads process.env.
Generate an SBOM: Run npm sbom (available in npm 9+) or use a tool like Syft to generate a software bill of materials. Store this in your version control system alongside your code. When a malicious package is disclosed, you can grep your SBOM history to determine if you were affected and when.
Monitor outbound connections from dev workstations: Configure endpoint detection tools (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) to alert on unusual outbound connections from Node.js processes. PhantomRaven exfiltrated to attacker infrastructure—your EDR should have flagged the destination.
Audit existing installations now: Run npm list in every repository to inventory currently installed packages. Cross-reference against the PhantomRaven indicators of compromise (check Endor Labs' disclosure for package names). If you find a match, rotate every credential that existed in environment variables on affected systems. Assume compromise.
Train developers on package selection: Add supply chain security to your secure development training. Teach developers to check package age, download count, publisher verification badge, and GitHub repository before installing. This takes 30 seconds per package and catches most attacks.
The 81 packages still in the npm registry represent ongoing risk. Your verification gates need to run on every npm install, not just during CI. Developer workstations are now part of your attack surface.
