Verified Platforms
Quick Links
Where to Stay Secure
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Phishing trained you to distrust links. It never trained you to distrust the package you installed this morning.
The advice on how to protect your crypto wallet from malware almost always points outward: the fake app, the poisoned link, the stranger in your DMs. All real. All downstream. But the keys that drained in the last week of May 2026 did not leave through a link anyone clicked. They left through a dependency that ran on install, and through an AI assistant that read a file it was told to trust.
This walkthrough follows Ava, the one who reads pressure and geometry, who treats any system as a set of surfaces before it is a set of features. Her lens here is the attack surface for your keys: mapped as a structure, not a checklist.
Ava does not start with the wallet. She starts with everything upstream of it.
Because the wallet was never the soft part.
Ask where a private key lives, and the honest answer is: in more places than the wallet screen.
It sits in memory while you sign. It passes through the clipboard when you copy an address. It gets typed, so a keylogger sees it. It is held by the browser profile, the password manager, the environment variable inside a project you are building. Each of those is a place the key can leak, and none of them is the wallet app you were watching.
The familiar malware lives at this layer. Clipboard hijackers swap the address you pasted for the attacker's a half-second before you confirm. Keyloggers record the seed phrase as you type it. Info-stealers scrape the browser profile and the wallet extension's local storage and ship it off in one burst.
This baseline is now rented, not built. Stealer kits sell as a service, so draining a wallet no longer means writing malware, only pointing a commodity tool at a target. The volume climbed as the skill required fell.
This is the layer every security guide covers, and covering it matters: a hardware wallet that signs offline, an address you verify on the device's own screen, a seed you never type into a website. Kodex walks the full baseline in How to Secure Your Crypto Wallet.
Notice what every item on that list quietly assumes. It assumes the malware arrives as something you can refuse. A link you can decline. An app you can avoid. A file you can choose not to open.
Ava's question is the one that breaks the assumption. What protects you when the malware arrives as something you asked for?
That is not phishing.
That is the supply chain.
On May 22, 2026, a package called eth-security-auditor went up on PyPI. The name reads like a tool you would want on your side. It was the first thread of a campaign researchers later named TrapDoor.
By the time it was mapped, TrapDoor had poisoned 34 packages across more than 384 versions, spread over npm, PyPI, and Crates.io, according to the researchers at Socket who tracked the campaign. The names were chosen to look like exactly what a crypto or AI builder reaches for: solidity-deploy-guard, defi-threat-scanner, prompt-engineering-toolkit. Tools that sound like defense. The attacker even seeded GitHub repositories and discussions promoting these fake "security" workflows, so the packages would be found the way real tools are found, by someone looking to be safer.
Reaching for a tool called defi-threat-scanner is what you do when you are trying to be careful. The campaign turned that instinct into its delivery route.
The malicious code did not wait for you to run your program. It ran at install.
An npm package can execute a postinstall script the moment it lands. A Rust crate runs build.rs when it compiles. A Python package can execute code on import. All three fire before you read a single line of what you pulled in. So the instant you typed install, the payload was already reading the machine: SSH keys, AWS environment variables, GitHub tokens, browser profiles, and the wallet files for Solana, Sui, Aptos, and MetaMask, as The Hacker News documented across the affected registries. The stolen GitHub and cloud tokens were then validated against live APIs, so the attacker knew which keys actually worked before you knew anything was wrong. Multiply that across 384 versions and every machine that pulled a poisoned one inside the window, and the campaign was harvesting in parallel from everyone who typed install while it was live.
Code review is your defense against bad code.
It is no defense against code that runs before the review.
Ava frames it as a sequence problem, not a trust problem. You were going to audit the dependency. The dependency did not wait to be audited. The breach happened in the gap between install and read, a gap your workflow does not even register as a moment.
One detail should change how this feels. The median time for the campaign's packages to be caught was 5 minutes and 27 seconds. That is fast. Far faster than you would read a dependency tree by hand. And still slower than a postinstall script that finishes in under a second.
If you do not write code, this is not your direct exposure, and it is not nothing either. The funds sitting in a protocol, an app, or a desk you rely on live downstream of someone who does install packages. When their build machine leaks, your assets inherit the blast radius. The supply chain is collective. The loss is personal.
The newest layer of TrapDoor is the one without precedent, and it is why this stopped being only a developer story.
Some of the packages quietly modified two files: CLAUDE.md and .cursorrules. These are the instruction files that AI coding assistants read to learn how to behave inside your project. Into them, the campaign wrote a command. Then it hid the command with zero-width Unicode, characters that take up space in the file but render as nothing on screen.
You open the file. You see your normal project notes. The assistant reads the same file and sees an extra instruction you cannot: run a security scan, gather the findings, report them out. The Block described the payload as a staged framework built to make an AI agent discover and exfiltrate secrets on the operator's behalf.
So the theft is not done by the malware. It is done by your assistant, acting on an instruction it believes came from you. The tool you delegated to became the tool that drained you. Not because it was hacked, but because it was obedient.
This is the same convergence Kodex traced in real-time payment malware, where the attacker stops fighting for your credentials and instead bends a legitimate action you already trust. TrapDoor moves the idea up one level. It does not bend your action. It borrows your agent's. And the cohort of people who now lean on an AI assistant to read their files, summarize their work, and run their errands is growing well past the people who write Solidity.
The vector also generalizes past config files. An assistant that reads your web pages, your documents, and your email can be handed an instruction buried in any of them. Hidden text inside content an agent trusts is a category of attack, not one clever package.
Ava's read is blunt. Any tool you grant read access to your machine is part of your wallet's security perimeter. An AI assistant has read access by design.
Every guide repeats the rule: only use trusted sources. It is the advice that quietly fails here, and the reason is worth stating precisely.
The rule assumes the threat looks untrusted. A sketchy site. An unsigned app. A sender you have never heard of. TrapDoor inverts that. Its packages lived inside npm, PyPI, and Crates.io, the registries the entire ecosystem treats as trusted by default. They carried names like defi-threat-scanner, branding themselves as the very tools you would install to be safer. The registry was trusted. The package name was trusted. The AI assistant was trusted.
The malware was not hiding from your trust.
It was wearing it.
So "trusted source" has to stop meaning a place or a name you recognize, and start meaning behavior you have verified. A package pinned to a known-good version instead of pulling whatever is newest. A dependency whose install scripts you have actually opened. A config file you treat as executable, because to an AI agent reading it, that is what it is. Kodex covers the human version of this exploited trust in Crypto Social Engineering Scams, and the supply chain runs the same play against your machine instead of your inbox.
Trust placed in a name is not a control.
Trust placed in verified behavior is.
You cannot patch your way out of this with one more scanner. The defense is structural: separate the places your keys live, transact, and get built, so a breach in one cannot reach the others. Ava maps it as three layers, each with a different job.
Where your keys live. Long-term holdings belong in cold storage, on a hardware wallet, on a device that never installs packages and never runs an AI assistant. If it does not touch a build, a postinstall script cannot touch it. Isolation here is not paranoia.
It is the entire defense.
Where you transact. Day-to-day moves run through a hot wallet that never holds the full balance, with least-privilege token approvals you revoke once you are done. The link-and-approval hygiene that lives at this layer is the ground Kodex covers in Crypto Scams - How They Steal Your Keys. A drained signing wallet is a bad afternoon. A drained cold wallet is the end of the story.
Where you build and run tools. The machine that installs dependencies and reads config files should be the machine with nothing worth stealing on it. No seed phrase. No exchange API key with withdrawals enabled. Pin your dependencies, read the install scripts, and treat CLAUDE.md and .cursorrules as code that executes, because through your assistant, it does.
If you think a machine with key access was already exposed, treat it as hostile and move first, diagnose later. On a separate clean device, generate a new wallet and move the funds before anything else. Revoke the token approvals you granted recently. Rotate exchange passwords and 2FA, and recreate any API keys with withdrawals disabled and behind an IP allowlist. Separating the layers is what keeps this list short, because the cold keys were never on the machine that got hit.
Each baseline defense covers the layer it was built for and misses the one beside it. Here is where each attack lands, and what actually stops it.
| Attack layer | What it touches | Why standard advice misses it | What actually blocks it |
|---|---|---|---|
| Phishing link, fake app | The wallet you knowingly open | Assumes you clicked something obviously wrong | Refusing links you did not request, bookmarking the real site |
| Clipboard or keylogger malware | Keystrokes and copied addresses on a live device | Treated as the whole malware story | Hardware wallet signing offline, verifying the address on its own screen |
| Malicious dependency | The machine, at install, before any code review | "Use trusted sources" assumes the source looks bad | A separate build machine, pinned and reviewed dependencies, no keys present |
| AI-assistant injection | The agent you handed read access | No common advice exists yet, and the instruction is invisible | Keeping keys off any machine an agent can read, treating config files as code |
Every one of those defenses reduces to one move. Put distance between your keys and anything that executes on your behalf.
The attack surface for your keys is not a fixed thing you can finish securing. It grows by one every time you add a tool, a dependency, an assistant, a convenience. Each addition earns read access to the machine, and read access is the only thing the theft ever needed.
So the discipline that protects a crypto wallet from malware in 2026 is not "be more careful with links." It is narrower and harder: treat every tool with reach into your machine as part of the wallet, and give the keys themselves nowhere interesting to sit. If you want the structured version of that habit, the Web3 Security courses build it from the ground up.
Phishing taught you to watch the door. The keys are walking out through the supply line.
