TrapDoor planted 34 malicious packages across npm, PyPI, and Crates.io in a credential-theft campaign aimed at crypto and AI developers — and its most aggressive move was trying to poison AI coding assistants, not just package managers.
The campaign was publicly named by Socket Security on May 25, 2026, with earliest traces on May 19 and a main wave landing May 22 at 20:20 UTC, according to Notebookcheck. By publication, attackers had pushed 384 versions across the three registries.
TrapDoor Campaign Hits npm, PyPI, and Crates.io With 34 Malicious Developer Packages
The first confirmed package was eth-security-auditor on PyPI. Dozens followed from a cluster of accounts publishing in bursts across three major open-source registries.
The package names were built to look useful inside crypto, DeFi, Solana, and AI development workflows. Reported examples include prompt-engineering-toolkit, defi-threat-scanner, wallet-security-checker, and solidity-deploy-guard.
The core question for security teams is simple: would those names have looked suspicious during a fast-moving build or audit cycle?
TrapDoor’s payload was consistent across all 384 versions. It targeted crypto wallets, SSH keys, cloud credentials, AWS and GitHub tokens, browser data, and environment variables.
| Registry | Reported execution path | Reported behavior |
|---|---|---|
| npm | postinstall hooks | Drops trap-core.js, validates stolen tokens against live AWS and GitHub endpoints, and attempts persistence through cron jobs, systemd, Git hooks, and SSH |
| PyPI | import-time execution | Fetches JavaScript from an attacker-controlled GitHub Pages domain, letting the attacker update payload code without changing the PyPI package |
| Crates.io | build.rs script | Locates local keystores and sends XOR-encrypted data to GitHub Gists |
Socket’s reported median detection time was five minutes and 27 seconds. That speed matters, but it does not erase the risk for any machine that installed or imported one of the packages before detection.
AI Coding Workflows Create a High-Value Target for Credential Theft
TrapDoor did not stop at malicious dependencies. It also planted .cursorrules and CLAUDE.md files into target repositories, using zero-width Unicode characters to hide instructions that are invisible or hard to spot in normal text review but still readable by software.
Those files matter because AI coding tools can read project-level instructions before suggesting, editing, or running code. In TrapDoor’s case, the hidden instructions were designed to make an AI coding assistant see what looked like a routine security scan while actually driving secret exfiltration from the local machine.
Could a reviewer approve the file while the AI assistant reads a different operational meaning? That is the danger Socket’s reporting points to.
The attacker opened pull requests against BrowserUse, LangChain, and LangFlow to test whether those poisoned files could survive normal review. If merged, the source material says every developer opening the repository with an AI coding tool could become a target.
For related MLXIO reading on this trust boundary, see Claude Code Exposes the New Coding Risk: Blind Trust and Google Antigravity 2.0 Bets $100 on AI Coding Agents.
The reported spread mechanism is narrower than some broader supply-chain fears. Based on the supplied reporting, TrapDoor’s confirmed routes were package install hooks, import-time execution, Rust build scripts, and poisoned repository instruction files — not a verified campaign of copy-pasted AI-generated commands.
MLXIO analysis: the attacker appears to be moving the target from “bad package in a registry” to “trusted developer workflow.” That shift makes the editor and AI assistant part of the execution path, not just passive tools around the code.
Developers Should Audit Dependencies, Secrets, and Package Install History
The most immediate work is verification, not panic. Teams should review recent installs from npm, PyPI, and Crates.io around the reported TrapDoor window, especially anything added near or after May 22 at 20:20 UTC.
Which machines actually ran the package code? That question matters more than whether a dependency merely appeared in a file.
Practical checks should start with the data TrapDoor reportedly sought:
- SSH keys: Identify developer machines and CI runners that may have exposed keys.
- Cloud credentials: Review AWS-related tokens and environment variables present on affected systems.
- GitHub tokens: Check local developer environments and automation contexts where tokens may have been stored.
- Wallet material: Treat exposed crypto wallet files or keystores as high-risk.
- Browser data: Consider whether local browser credential stores were accessible on affected devices.
MLXIO analysis: credential rotation is justified where execution is confirmed or strongly suspected, because the reported malware did not merely stage files; it validated tokens against live AWS and GitHub endpoints and attempted persistence through local mechanisms.
Dependency pinning, approval workflows for new packages, secret scanning, and least-privilege cloud credentials can reduce blast radius, but none of those controls should be treated as proof that no compromise occurred. Pinning helps control change; it does not make a newly approved malicious package safe.
Teams using AI coding assistants should also review repository files that guide assistant behavior. .cursorrules and CLAUDE.md should be treated as security-sensitive when they can influence tool actions, especially if they arrive through external pull requests.
For a separate cloud-secrets failure mode, MLXIO readers can also compare the TrapDoor credential-theft angle with CISA Spilled Cloud Keys on GitHub — Then Said No Harm.
Package Registry Responses and Victim Scope Will Shape the Next Phase of the TrapDoor Investigation
The next phase depends on what npm, PyPI, Crates.io, and researchers publish after the initial disclosure. The supplied source does not provide download counts, confirmed victim names, or verified losses.
How many developers actually executed TrapDoor packages before detection? That remains one of the largest open questions.
Investigators will likely focus on whether the publishing accounts were coordinated manually or automated, how package names were selected, and whether the pull requests to BrowserUse, LangChain, and LangFlow were probes or part of a wider attempt to seed AI-readable instructions into trusted repositories.
There is also no attribution in the supplied material tying TrapDoor to a known threat actor. For now, it is best described as a cross-registry supply-chain campaign with a credential-theft payload and an AI-assistant poisoning component.
The watch item is not only whether the identified packages disappear from registries. It is whether maintainers begin reviewing AI instruction files with the same suspicion they already apply to install scripts, build hooks, and CI configuration. TrapDoor’s message is blunt: if a tool can read instructions and act on them, attackers will try to write those instructions first.
Impact Analysis
- TrapDoor shows attackers are targeting AI coding assistants as a software supply-chain infection path.
- The campaign used trusted package registries to reach crypto, DeFi, Solana, and AI developers during normal workflows.
- Its payload targeted high-value developer secrets including crypto wallets, SSH keys, cloud credentials, AWS and GitHub tokens, and environment variables.
