Earlier this week, attackers pulled off a short-lived but high-profile software supply chain attack on npm, the world’s largest registry of open-source code.
They compromised the account of Josh Junon (known online as Qix), the maintainer of hugely popular packages like chalk and debug. With that access, they slipped bad code into those libraries and pushed out malicious updates to millions of apps.
The malware had one target: crypto wallets in the browser. If someone tried to send funds, the code would intercept the transaction and redirect it to the attacker’s address.
Fortunately, the updates were discovered in under two hours. The community responded immediately, npm removed the compromised versions, and the total theft amounted to only about $1,000. What could have been a catastrophic compromise turned into a near miss — thanks to quick detection and smart practices like version locking.
What is npm, and why does it matter?
Think of npm as the world’s biggest app store for developers. Instead of buying apps, developers pull “packages” – tiny building blocks of code – to assemble into bigger applications. Billions of downloads happen each week. If someone slips a poisoned package into that store, it’s like tainting the supply chain at the factory level: every app that uses it could be at risk.
This week, that nightmare scenario happened. Attackers tricked a maintainer of some of npm’s most popular packages, hijacked their account, and uploaded new versions laced with malware. These packages are used in millions of websites and apps, making the attack one of the largest supply chain compromises in npm’s history.
How the attack happened
The story starts with an email. The maintainer of some of npm’s most popular packages - including chalk (used to make terminal text colorful) and debug (a logging tool) - received what looked like a support notice from npm. It came from a domain that looked official enough (npmjs[.]help). Inside was a request to “re-authenticate” and reset two-factor authentication.
It was a phishing trap. The maintainer entered their login codes, handing the attackers full access to their npm account. With that single misstep, the attackers held the keys to publish new versions of packages downloaded billions of times a week.
And they wasted no time. They pushed out fresh versions of at least 18 popular packages, hiding new malicious code in the updates.
What the malware actually did
Here’s where the attackers got clever - and also sloppy.
The poisoned packages were designed to lie dormant in most environments. If you were just running the code on a server or command line, nothing happened. But if the package ended up in a browser-based app, the trap was sprung.
The malware secretly attached itself to key parts of the browser:
It hooked into basic web requests that happen on every site you visit.
It watched for signs that a crypto wallet like MetaMask was being used.
It scanned for anything that looked like a bitcoin, ethereum, or solana address.
When a transaction was triggered, the malware quietly altered the details inside the browser before the wallet created the final transaction. Specifically, it swapped out the legitimate recipient’s wallet address for one controlled by the attacker. To the victim, everything appeared normal — the wallet still displayed the right amount and prompted for confirmation. But the destination field had already been changed behind the scenes. Once the transaction was signed and sent, the funds went straight to the attacker instead of the intended recipient.
This is one of the most insidious and hard to recognize attacks. It’s a similar attack pattern to the ByBit hack, which resulted in over $1B stolen.
The internet notices
The compromised packages didn’t stay hidden for long. Within about an hour of the malicious updates being published, security researchers digging into the new versions noticed unusual behavior. They posted their findings on X and Bluesky, sharing screenshots of the suspicious code and tagging other developers to spread the word.
From there, the warnings snowballed. Other researchers began confirming the issue, threads appeared explaining which versions were affected, and developers started locking their projects to safe releases. By the time npm was formally alerted and pulled down the malicious packages, the community had already created a clear picture of what was happening and which versions to avoid.
That speed was critical. Production apps don’t typically pull the very latest package updates every minute — most use locked dependencies or require manual updates. The quick response from researchers and developers meant that very few real-world apps had a chance to even touch the compromised versions before they were removed.
The damage was smaller than expected
Given the scale — billions of downloads per week across affected packages — you’d expect chaos. Instead, the actual theft amounted to a little over $1,000 total, spread across a handful of stolen transactions.
Why so little?
Short window: The malware only lived for about an hour before being yanked.
Execution flaws: The code targeted only certain wallet flows in browsers. If you weren't sending funds in that moment, you weren't at risk.
Community speed: Security Twitter/X lit up almost instantly, and npm moved fast to roll back the changes.
What could have been a catastrophic supply chain collapse became more like a near miss.
🔑 Key Insight: This attack was stopped quickly, and the impact was small. Next time the outcome could be very different — which is why your bitcoin security has to be ready for the worst case.
Why Casa users were never at risk
This attack specifically targeted browser-based wallets. Casa avoids that risk by design. All sensitive actions — like sending or receiving bitcoin — happen inside the Casa mobile app, not in a web browser. That means malicious scripts like these simply can’t interfere.
On top of that, Casa locks and reviews its dependencies, so sudden upstream changes never flow directly into production. This combination of architecture and process ensured Casa users were completely insulated from the npm incident.
🔑 Key Insight: Design choices matter. Keeping critical actions out of the browser is one of the simplest, most effective protections against modern attacks.
Curious how Casa works and what makes it different from an exchange? In this video, our team answers the most common questions we hear about bitcoin security — from what happens if Casa disappears, to how multisig works, to what to do if you lose a key. Whether you’re new to self-custody or leveling up your security setup, this Q&A covers everything you need to know about protecting your bitcoin with Casa.