What Happened
On May 22, 2026, at 8:20 p.m. UTC, attackers launched a coordinated supply chain attack across three major package registries. The TrapDoor operation deployed 34 malicious packages spanning 384 versions across npm, PyPI, and Crates.io. The malware targeted developers in crypto, DeFi, Solana, and AI communities, stealing credentials and compromising development environments for further attacks.
Socket's research team identified the campaign after detecting suspicious patterns in package behavior across all three ecosystems. The attack used AI-related project files and legitimate-looking package names to bypass security checks.
Timeline
May 22, 2026, 8:20 p.m. UTC: First malicious package published to npm
May 23-June 15, 2026: Attackers rapidly published multiple versions across all three registries to evade detection
Mid-June 2026: Socket identifies cross-ecosystem patterns and publishes findings
Current status: Packages removed from registries, but compromised developer environments remain at risk
The attackers' strategy of proliferating versions created a moving target. By the time one version was flagged, several more were live. This scale across three ecosystems simultaneously demonstrates a level of operational maturity not seen in previous supply chain attacks.
Which Controls Failed or Were Missing
Dependency verification: Development teams installed packages without verifying cryptographic signatures or comparing checksums against known-good versions. Most organizations lack tools to automatically validate package integrity before installation.
Build environment isolation: Developers ran npm install, pip install, and cargo build commands in environments with access to production credentials, API keys, and SSH keys. The malware harvested these immediately upon installation.
Behavioral monitoring: The packages executed network calls and file system operations during installation hooks. Standard developer workstations don't monitor for this behavior because package managers execute arbitrary code by design.
Registry monitoring: Security teams weren't tracking new package publications or version updates for dependencies in their stack. The first indication of compromise came from Socket's external research, not internal detection.
Secrets management: Credentials were stored in environment variables, configuration files, and shell history — all locations the malware targeted. No secrets rotation occurred after the compromise window.
What the Standards Require
PCI DSS v4.0.1 Requirement 6.2.4 mandates that "bespoke and custom software are developed securely," including third-party components. You must maintain an inventory of software components and monitor for vulnerabilities. Installing unvetted packages from public registries without verification violates this control.
NIST 800-53 Rev 5 SA-10 requires organizations to "require the developer of the system, system component, or system service to perform security and privacy testing and evaluation." When you install third-party packages, you're incorporating developer-supplied components. The control expects you to validate these components meet your security requirements before integration.
ISO/IEC 27001:2022 Annex A.8.30 applies when you use external code. You must "establish and implement security requirements for the development of systems that involve outsourced parties." Public package registries are outsourced development by definition. The standard expects documented procedures for evaluating and accepting third-party code.
SOC 2 Type II CC6.1 requires that "the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." Credentials in environment variables accessible to package installation scripts fail this control. The malware's ability to exfiltrate keys demonstrates inadequate access restrictions.
These standards don't prohibit using npm. They require you to verify what you install, restrict access, monitor actions, and maintain an inventory of your software.
Lessons and Action Items for Your Team
Implement package verification now. Before installing any package, verify its signature and checksum. For npm, use npm audit signatures. For PyPI, verify wheel signatures with pip-audit. For Rust, enable cargo-crev to use community reviews. If the package isn't signed, document why you're accepting that risk.
Isolate your build environments. Run npm install and equivalent commands in containers or VMs without access to production credentials. Use separate service accounts for CI/CD with minimal permissions. If malware executes during installation, it should find nothing worth stealing.
Deploy package registry monitoring. Set up alerts for new packages in your dependency tree. Tools like Socket, Snyk, or GitHub's Dependabot can flag suspicious packages before your team installs them. Configure these to block installation automatically in CI/CD pipelines.
Rotate all credentials immediately if you installed packages during the compromise window (May 22-June 15, 2026). The malware specifically targeted API keys, SSH keys, and authentication tokens. Assume any credential accessible to your development environment was exfiltrated.
Build a software bill of materials (SBOM). Use tools like syft, cdxgen, or trivy to generate machine-readable inventories of every component in your applications. Update these with every build. When the next supply chain attack hits, you'll know in minutes whether you're affected.
Restrict package installation permissions. Require approval workflows for adding new dependencies. One organization reduced their attack surface by 60% by making developers justify new package additions in pull requests. The friction surfaces risk before installation, not after compromise.
Monitor post-installation behavior. Deploy endpoint detection on developer workstations that flags unusual network connections, file access patterns, or process spawning during package installation. Yes, this creates false positives. That's better than discovering months later that your entire development team's credentials were stolen.
The TrapDoor campaign succeeded because it exploited the gap between "packages are convenient" and "packages execute arbitrary code." Your security program needs to close that gap before the next campaign targets your stack.
