TrapDoor is worth covering because it shows what modern supply chain malware looks like when the attacker is not loyal to a single ecosystem.
This campaign spanned npm, PyPI, and crates.io at the same time. That matters because it targeted developers by workflow rather than by language. If you worked in crypto, DeFi, AI, or security tooling, the attacker wanted your machine, your credentials, and your wallet material regardless of whether you installed JavaScript, Python, or Rust packages.
What happened
Public reporting from Socket described a May 2026 campaign involving dozens of malicious packages and hundreds of related versions or artifacts across npm, PyPI, and crates.io.
The package names were designed to look like ordinary helper tools for:
- crypto and wallet safety
- Solidity or Move development
- local environment setup
- model routing and prompt tooling
- development or security automation
That disguise was the point. These were not broad consumer lures. They were trying to land in high-value developer environments.
Why this campaign mattered
TrapDoor mattered because it connected three trends that are getting harder to separate:
- cross-registry package compromise
- workstation and developer-secret theft
- AI-tooling persistence and prompt-path abuse
In npm, the campaign used install-time hooks and a shared payload to harvest secrets and establish persistence.
In PyPI, packages executed remote JavaScript on import, which is a nasty reminder that a Python package can still be a delivery layer for code hosted somewhere else.
In crates.io, malicious build.rs scripts targeted Sui and Move developers and exfiltrated wallet-related material during the build process.
Why this was more than simple package malware
The scary part of TrapDoor was not just that it stole secrets. It treated the developer environment as a durable operating surface.
Public reporting described persistence and propagation paths including:
.cursorrulesCLAUDE.md- Git hooks
- shell hooks
systemdcron- SSH-based reuse of stolen access
That makes the attack much closer to a developer-environment takeover than a one-time malicious install.
Why the AI angle matters
One of the more interesting parts of TrapDoor was the attempt to abuse AI coding workflows directly.
The campaign reportedly planted or referenced files such as .cursorrules and CLAUDE.md to influence future tool behavior. That is important because it shows attackers experimenting with a new question: if package malware lands on a developer machine, can it also shape what the developer’s AI tools do next?
Even when the exact effect is inconsistent, the direction is clear. AI tooling is now part of the attack surface.
The implications for engineering teams
The first implication is that supply chain defense cannot be registry-specific anymore. A team may use npm, PyPI, and crates.io in the same environment, so the defensive model has to cover the whole developer workstation.
The second implication is that crypto and AI developers are especially attractive targets because their machines often hold a mix of:
- SSH keys
- cloud credentials
- GitHub tokens
- wallet data
- local browser secrets
- agent and editor configuration
The third implication is that post-install persistence on a workstation can turn a dependency incident into a long-lived compromise.
What teams should change
1. Treat developer workstations as high-value infrastructure
If your machine can publish code, access wallets, deploy services, and drive AI tooling, it is not just a laptop. It is part of production risk.
2. Add cooldown and verification controls across registries
Do not apply strict controls to one package ecosystem and leave the others as open highways.
3. Watch AI-tool configuration files like other persistence paths
Files such as .cursorrules and CLAUDE.md should no longer be treated as harmless documentation by default.
4. Assume host compromise when malicious packages were installed
Uninstalling the package is not enough if the malware harvested secrets or planted persistence.
Mitigation advice
If you suspect a machine installed TrapDoor-linked packages:
- Isolate the machine and stop further package installs from it.
- Remove malicious dependencies and rebuild from known-good locked versions.
- Rotate GitHub, cloud, API, SSH, and wallet-related credentials reachable from that host.
- Inspect for persistence in shell hooks, Git hooks,
systemd,cron,.cursorrules, andCLAUDE.md. - Review outbound traffic and repository activity for signs of credential validation or reuse.
Related links
- Socket analysis of the TrapDoor campaign
- Socket campaign tracking page for TrapDoor
- Attacker-linked GitHub Pages infrastructure referenced in reporting
- Attacker-linked AUDIT-MATRIX document referenced in reporting
The lesson from TrapDoor is that software supply chain attacks are increasingly built around the developer, not just the dependency graph. Once that is true, every registry you use and every tool that shapes your local environment becomes part of the same security problem.