TrapDoor Malware Hits npm, PyPI and Crates.io in Crypto Supply Chain Attack

TrapDoor is a supply chain attack that hid malware inside open-source packages used by crypto, blockchain, and AI developers across npm, PyPI, and Crates.io. The goal was ugly and familiar: steal wallet keys, cloud credentials, GitHub tokens, SSH keys, and anything else that could unlock money or infrastructure.

• 34+ malicious packages spread across npm, PyPI, and Crates.io
• Targets: crypto, blockchain, and AI developers
• Data stolen or targeted: wallet keys, cloud creds, GitHub tokens, SSH keys
• AI workflow tampering: hidden commands in .cursorrules and claude.md

The campaign was uncovered by Socket, which flagged more than 34 malicious packages and hundreds of related versions after finding them spread across three of the biggest open-source ecosystems on the planet: npm, the JavaScript package repository; PyPI, the Python package repository; and Crates.io, the Rust package repository. In plain English: attackers went where developers already go to grab tools fast, trust too much, and move on with their day. That’s exactly the kind of habit supply chain attackers live for. They don’t need to kick down the door when developers are happily installing a forged keycard.

How TrapDoor spread

These packages were not obvious junk. They were dressed up to look like useful developer utilities, especially for people working in crypto and AI. Some pretended to be wallet security tools, DeFi scanners, Solidity helpers, Move and Sui development tools, or AI-related utilities. Fake package names included wallet-security-checker, defi-risk-scanner, solidity-build-guard, move-compiler-tools, and llm-context-compressor.

That’s classic social engineering. The attacker doesn’t have to beat your firewall if they can convince you to install the malware yourself. Package managers make that easier than it should be. Developers are under constant pressure to ship, test, patch, and automate. That speed is useful. It’s also a loaded gun if nobody checks the chamber.

Each ecosystem had its own execution trick. On npm, the malware used post-install scripts. On PyPI, it could run remote JavaScript during import. On Crates.io, harmful build.rs scripts executed during compilation. Different packaging systems, same outcome: malicious code ran because the developer trusted the install pipeline.

For non-developers, that means the software dependency itself became the infection vector. A package is supposed to be a reusable building block. In TrapDoor, it was the hiding place for the attacker’s payload. Very charming. Very rotten.

What the malware was after

Once on a machine, TrapDoor went after a grimly predictable list of high-value data: private keys, passwords, GitHub access tokens, cloud credentials, browser-stored data, and SSH keys. It also validated stolen credentials, tried to move laterally over SSH, and set up persistence for long-term access.

That last part matters. Persistence means the attacker wasn’t just trying to grab a quick payday and disappear. They wanted to stay inside the environment, keep access alive, and potentially move from one machine to another. In security terms, that’s the difference between a smash-and-grab and someone moving into your apartment and changing the locks.

Crypto developers are especially juicy targets because a compromised workstation can expose far more than a browser login. It can reveal wallet keys, exchange API credentials, production secrets, node access, deployment tokens, and signing material. Steal the right key and you may not need to “hack” anything else. The funds, code, or infrastructure may already be yours to misuse.

And yes, the old “just keep your seed phrase safe” advice still matters, but modern compromise is broader than that. A developer laptop can be the single point of failure for an entire project. That’s not a crypto problem alone; it’s a software supply chain problem with very expensive consequences.

Why crypto and blockchain teams were in the crosshairs

The targeting pattern wasn’t random. The malicious packages were styled to appeal to people working on smart contracts, DeFi tooling, AI helpers, and newer ecosystems like Sui and Move. Solidity developers were also in the blast radius.

That makes sense. Attackers follow the money, and crypto remains one of the fastest ways to turn stolen credentials into immediate value. A compromised GitHub token can expose private repositories or let an attacker tamper with code. Stolen cloud credentials can open the door to servers, nodes, dashboards, or data stores. A leaked SSH key can give direct access to production machines. In a centralized company, that’s bad. In crypto, it can be catastrophic.

There’s also a brutal irony here. A lot of crypto culture is built around skepticism, self-custody, and removing blind trust from money. Yet many teams still depend on huge chains of third-party packages they barely inspect. Decentralization doesn’t mean “trust random npm junk because it looks helpful.” That’s not cypherpunk. That’s negligence with a hoodie on.

The AI angle is the clever part

TrapDoor didn’t just target codebases. It also tried to poison AI-assisted development workflows by tampering with files like .cursorrules and claude.md. Those files can help define how tools like Cursor or Claude should behave inside a project, which makes them a neat little attack surface for anyone trying to manipulate future AI sessions.

The malware used zero-width Unicode characters to hide commands inside what looked like normal text. Zero-width characters are invisible formatting characters, so a malicious instruction can be tucked into a file without looking obvious to the human eye. The result is a kind of stealth note left for the AI assistant: read this later, then do the bad thing.

That matters because more developers now lean on AI coding assistants for speed, debugging, and even basic security checks. If an attacker can poison those workflows, the assistant may follow hidden instructions or run fake scans without the human noticing the trick immediately. AI doesn’t magically cleanse a poisoned environment. Feed it garbage, and it can become a very efficient garbage dispenser.

This is a bigger issue than one campaign. As AI tools become part of everyday development, they also become part of the trust boundary. A repository is no longer just code. It may also contain instructions for the machine that helps write, review, and execute that code. That’s useful, but it’s also a fresh way for attackers to sneak in through the side door.

What this says about open-source security

Open source is not the villain here. Blind trust is. Package ecosystems like npm, PyPI, and Crates.io are incredibly useful, but they also create a giant chain of trust with a lot of weak links. Attackers know developers are busy. They know people reuse names that sound plausible. They know dependency sprawl is real. So they exploit it.

The real lesson is not “stop using open source.” The real lesson is “stop treating open source like magic.” Audit dependencies. Verify maintainers. Pin versions. Review install scripts. Use least-privilege access. Isolate build environments. Scan for secrets. Rotate anything that may have been exposed. And for the love of all things sane, don’t install packages on vibes alone.

Socket reported the malicious packages to the relevant repositories and flagged them as malicious, but the larger problem remains. The more developers rely on automation, AI helpers, and third-party dependencies, the more attractive the attack surface becomes. The tools are powerful. The trust model is fragile. And attackers absolutely know it.

What developers should do now

• Audit dependencies before installing them
• Verify package maintainers and publication history
• Pin versions and monitor changes
• Inspect install, import, and build scripts
• Use secrets managers instead of hardcoding credentials
• Rotate GitHub tokens, SSH keys, and cloud keys if exposure is possible
• Keep build and development environments isolated
• Treat AI workflow files like code, not decoration

For non-developers, the takeaway is simple: the software developers trust can be weaponized, and that has direct consequences for exchanges, wallets, protocols, and users. One bad dependency can compromise a machine. One compromised machine can compromise a project. In crypto, that can become stolen funds and a very expensive lesson in why “convenient” is not the same thing as safe.

Key questions and takeaways

What is TrapDoor?

TrapDoor is a malicious supply chain campaign that spread through open-source package repositories to infect developer machines and steal sensitive credentials.

Who was targeted?

Developers in crypto, blockchain, and AI, especially those likely to store private keys, cloud access, and production secrets on their workstations.

How did the attackers spread the malware?

They published fake but believable packages on npm, PyPI, and Crates.io, then used platform-specific execution methods to run malicious code.

What information was targeted?

Private keys, passwords, GitHub tokens, SSH keys, cloud credentials, and browser-stored data.

Why is this especially dangerous for crypto developers?

Compromised keys or credentials can lead to stolen funds, project takeover, production breaches, and follow-on attacks across teams and infrastructure.

What’s the AI angle here?

Attackers tried to poison AI coding assistant instructions by modifying .cursorrules and claude.md, using hidden Unicode characters to conceal commands.

What does this say about open-source security?

Open source is incredibly useful, but blindly trusting packages is reckless. Verification, dependency auditing, and least-privilege practices are essential.

What should developers take from this?

Don’t install dependencies on vibes alone. Audit packages, inspect maintainers, verify provenance, and assume that anything useful-looking could still be a trapdoor waiting to be opened.