TrapDoor is a good example of where software supply chain attacks are heading. It was not limited to one package manager, one language, or one developer community. According to Socket, the campaign spread across npm, PyPI, and Crates.io, using malicious packages that looked like developer utilities, security helpers, crypto tooling, AI tools, and project setup packages. The goal was direct: get onto developer machines and steal anything that could unlock wallets, repositories, cloud accounts, or infrastructure.
Socket reported the campaign on May 24, 2026, tracking it as TrapDoor. The activity involved more than 34 malicious packages and 384+ related versions and artifacts across the three ecosystems. The earliest package Socket observed was uploaded to PyPI on May 22, 2026, and the campaign continued in waves through multiple accounts and registries.
Why TrapDoor Matters
Most malicious package campaigns stay inside one ecosystem. TrapDoor did not.
It crossed JavaScript, Python, and Rust package registries. That matters because modern development teams rarely live in one language anymore. A crypto or AI project might use Node.js for tooling, Python for automation, and Rust for wallet, blockchain, or performance-sensitive components. TrapDoor took advantage of that mixed environment.
The packages were aimed at developers in crypto, DeFi, Solana, Sui, Move, AI, and security communities. These are high-value targets because their machines often hold wallet files, private keys, cloud credentials, GitHub tokens, SSH keys, and access to production or staging systems.
This was not just malware looking for random browser cookies. It was built for developer environments.
How the Attack Worked
TrapDoor used different execution methods depending on the ecosystem.
In npm, the malicious packages relied on install-time execution. Some packages used postinstall behavior to run a shared payload that searched the local system for secrets and developer credentials. Socket described the npm payload as a large credential harvester that could scan for sensitive files, validate some stolen credentials, attempt persistence, and look for ways to move deeper into a developer's environment.
In PyPI, the packages executed when imported. Socket reported that the Python packages downloaded remote JavaScript and ran it locally. That is especially risky because import-time execution can surprise developers. A package may look harmless until a normal import triggers behavior the user never expected.
In Crates.io, the Rust packages abused build-time execution. Rust packages can use build scripts that run during compilation. Socket said TrapDoor used this path to target wallet-related developer data, especially in the Sui and Move ecosystem.
That cross-ecosystem design is the important part. TrapDoor adapted to the normal behavior of each package manager instead of using one generic trick everywhere.
What It Tried to Steal
TrapDoor was built to collect developer secrets and crypto-related data. Socket's research says the malware targeted:
- Crypto wallet data and private keys
- SSH keys
- AWS credentials
- GitHub tokens
- Browser profile data and login databases
- Wallet extension data
- Environment variables and
.envfiles - API keys
- Local development configuration files
The real danger is what happens after the first theft. A stolen wallet can lead to immediate crypto loss. A stolen GitHub token can expose private repositories. A stolen SSH key can open access to servers. A stolen cloud credential can turn a developer laptop compromise into an infrastructure incident.
That is why supply chain malware aimed at developers is so serious. Developers are not just users. They are often trusted paths into source code, build systems, cloud platforms, and release pipelines.
The AI Angle
One of the more notable parts of TrapDoor is its attempt to abuse AI development workflows.
Socket found that the campaign used files commonly read by AI coding assistants, including project instruction files. The idea appears to be straightforward: place instructions where an AI coding tool may later read them, then try to influence the assistant into running commands or treating malicious behavior as a normal security scan or development task.
This does not mean every AI coding assistant will blindly follow those instructions. But it shows where attackers are experimenting. They know developers are adding AI tools into their daily workflow, and they know those tools often read local project files for context.
That creates a new kind of supply chain risk. The package is not only trying to trick the developer. It may also try to trick the developer's tools.
Why the Package Names Worked
TrapDoor used names that sounded useful to the exact people it wanted to target.
The packages were framed around wallet safety, DeFi risk, environment loading, build helpers, prompt engineering, model routing, security auditing, and blockchain development. Developers often install small helper packages quickly, especially when they sound like they solve a specific problem.
This is how malicious packages get past human judgment. They do not need to look famous. They just need to look useful at the right moment.
A developer working on a wallet, smart contract, Sui project, Move project, or AI agent might see a package name that sounds relevant and install it without a second look. That is enough.
The Bigger Pattern
TrapDoor fits into a larger trend: attackers are moving closer to the developer.
Old-school malware often targeted end users. Newer supply chain campaigns target maintainers, build systems, package registries, CI/CD tokens, developer laptops, and now AI-assisted coding environments.
That shift makes sense. One compromised developer can be more valuable than hundreds of compromised consumer machines. Developers may have access to signing keys, internal repos, cloud dashboards, private package registries, and production deployment systems.
TrapDoor also shows that low-download packages can still matter. A package does not need millions of installs if it lands on the right machine. One install by a crypto developer with wallet keys or cloud access is enough.
What Teams Should Do
Teams working in crypto, AI, or security should review recent installs from npm, PyPI, and Crates.io, especially packages added around May 22–24, 2026. If a suspicious package was installed, treat the developer machine as potentially compromised and rotate exposed secrets.
Rotate GitHub tokens, SSH keys, cloud credentials, package registry tokens, API keys, wallet keys, and any credentials stored in local environment files.
For prevention, tighten how packages are introduced:
- Require review for new dependencies before they land in active developer environments
- Use lockfiles and dependency approval workflows
- Test risky packages inside isolated containers or disposable VMs
- Monitor and audit install scripts (
postinstall) and build scripts (build.rs) - Block packages that execute code during install unless there is a documented reason
- Keep secrets out of local project directories where possible
- Treat AI assistant instruction files (
.cursorrules,CLAUDE.md, similar) as code that needs review — they influence how developer tools behave
That last point is becoming more important. Files that guide AI tools can affect both developer behavior and tool behavior. They should not be accepted casually from unknown packages or unreviewed pull requests.
Final Takeaway
TrapDoor was not just another crypto stealer. It was a cross-registry developer attack built with ecosystem-specific execution paths, developer-targeted package names, and an early attempt to manipulate AI coding tools.
It used npm, PyPI, and Crates.io because real projects use all three. It targeted crypto and AI developers because those communities hold valuable credentials. It used normal package-manager behavior because that is where developers already place trust.
The lesson is clear: dependencies are not just code you import. They are code you allow to run inside your development environment.
That environment deserves the same protection as production.