Most wallet security advice assumes you are the weak point. Do not click the link, do not type your seed phrase into a website, do not approve a transaction you did not start. It is good advice and it covers the majority of losses. It also has nothing to say about the attack where you do everything correctly and the software itself turns on you, because somebody changed the code before it ever reached your machine.
That is a supply chain attack, and 2026 produced several aimed squarely at people holding crypto.
The one that went straight for private keys
In June 2026, an attacker published a poisoned version of the Injective SDK to npm, the package registry that nearly all JavaScript software pulls from. Socket's researchers documented how version 1.20.21 exfiltrated wallet private keys and mnemonics through code disguised as telemetry. Their timeline shows commits beginning at 20:06 on 8 June that look like the attacker testing access, with the malicious release published later that same evening.
Read that again with the ordinary developer in mind. Somebody building a wallet interface, a trading dashboard or a portfolio tracker ran a routine dependency update, got a version number slightly higher than the one they had, and shipped it. Nothing on their screen looked unusual. The package did what it claimed to do, and it also quietly forwarded the keys and recovery phrases it could reach.
The scale problem
The Injective case was targeted at crypto. The larger campaigns were not, which makes them worse rather than better.
On 30 March 2026, two malicious versions of axios appeared on npm after an attacker hijacked the lead maintainer's account, injecting a hidden dependency that installed persistent malware across macOS, Windows and Linux. Huntress covered the compromise of what is the most widely used JavaScript HTTP client in existence, downloaded over 100 million times a week. Almost every web application you touch has axios somewhere beneath it.
Before that came Shai-Hulud, the self-replicating worm that spread from one phished maintainer account across more than 500 packages, harvesting npm tokens, cloud credentials and GitHub secrets as it went, which Unit 42 traced in detail. Copycat versions kept surfacing into 2026 after the original malware leaked. The pattern in all three is identical: compromise one account high enough in the dependency tree, and the payload distributes itself through the normal update process that everybody is told to keep current.
Why this breaks the usual advice
Every rule you have been given about wallet safety assumes a boundary between trustworthy software and the attacker. Download the official app, check the URL, verify the signature. A supply chain attack does not cross that boundary, it starts on the inside: the official app, from the official source, with a valid signature, containing a component that was poisoned three layers down before anybody compiled it.
The Mini Shai Hulud campaign even shipped with valid provenance attestation, which is the cryptographic receipt meant to prove a package came from where it claims. When the proof of origin is itself accurate and the origin has been taken over, checking the proof tells you nothing useful.
What a hot wallet exposes here, and what it does not
A browser extension or desktop wallet keeps your keys in software on the same machine that runs everything else. Encrypted at rest, sure, and decrypted in memory the moment you unlock it to sign something. Code running with your user permissions on that machine can read what you can read, which is why the Injective package was able to walk off with mnemonics at all. The hot wallet is not badly built; it is operating in a place where a poisoned dependency shares the room with your keys.
This is the split people miss when they compare wallets on features. Hot wallets and cold wallets differ less in what they let you do than in what has to be compromised before your keys are readable.
Where the keys have to be instead
On Ryder One, private keys are generated inside an EAL6+ certified Infineon SLC38 secure element and never leave the chip. There is no file to read, no memory to scrape, and no code path by which a compromised npm package on your laptop can request them. Communication is NFC-only, with no USB data transfer, no Bluetooth and no WiFi, so the connection to a potentially compromised machine is a deliberate tap rather than an open channel.
That handles theft of the key. The subtler half of a supply chain attack is manipulation of what you sign, and the defence there is your eyes. A poisoned frontend can swap a destination address between what you see in the browser and what gets sent for signature. Every Ryder One transaction is displayed in full on the 1.6-inch AMOLED touchscreen, receive addresses can be verified on the device itself, and the confirmation button is wired directly to the secure element so nothing signs without a press. If the browser says one address and the device screen says another, the device is the one telling you the truth. Our own firmware is independently audited by Halborn, with the full report public.
Your recovery phrase is in the blast radius too
Worth being precise about, because the Injective package took mnemonics as well as keys. Any recovery phrase that has ever been typed into a computer, photographed, stored in a password manager or saved in a cloud note lives in software's reach, and a dependency compromise on that machine puts it within reach of whoever owns the payload.
The standard fix is to keep the phrase offline: paper first, then stamped metal once the amount justifies the effort, since metal survives water and fire. It is a proper upgrade, and it leaves your entire recovery resting on one object that has to survive theft, disaster and your own memory of where you put it. TapSafe Recovery removes that concentration. A Recovery Tag holds 50%, your paired phone holds the other 50% encrypted in your iCloud or Google Drive rather than on the handset, and optional Recovery Contacts hold 25% each without ever seeing wallet information. It is built on a custom implementation of Shamir's Secret Sharing, while the BIP-39 phrase stays available on the device as a last resort, so you keep the option of walking away to other hardware.
What to do about it
You cannot audit npm, and neither can we. What you can do is reduce how much a compromised machine is able to give away. Keep long-term holdings on a device that signs without exposing keys, treat any phrase that has touched a computer as spent and move those funds to a wallet generated on hardware, and read the destination address on the device screen every time rather than trusting what the browser renders. For software wallets you keep for daily use, hold an amount you would be annoyed rather than wrecked to lose.
The industry keeps learning this the same way. Somebody's account gets phished, a version number ticks up, and the update everyone was told to install carries something extra. Your keys should be somewhere that news cannot reach.
Ready to move your keys off the machine running everything else? Get your Ryder One for 149 USD.
Meta description: A supply chain attack on a crypto wallet skips every rule you follow. How poisoned npm packages stole keys and mnemonics in 2026, and where keys belong instead.
Target keyword: supply chain attack crypto wallet
Share: