A phishing email, poisoned code, and a near miss for millions of apps. Our deep dive into the npm supply chain hack.
View in browser
Casa

Take control of your digital future

image-security-briefing (2)

Deep dive: inside the npm supply chain attack

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.

    ChatGPT Image Sep 12, 2025, 01_37_36 PM

    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.

    68bf028d86e3642f1268253f_050c42b9

    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.

    68bef52fd46522cb992c2219_4f550d2c

    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.

    Screenshot 2025-09-12 at 06.59.20

    Why so little?

    1. Short window: The malware only lived for about an hour before being yanked.
    2. 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.
    3. 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.

    Read more
    ee4beef9-2513-474a-9cb7-6c32a97ecee3-1

    Watch: What you need to know about bitcoin security

    Q&A: What you need to know about bitcoin security | Casa

    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.

    Watch now
    ee4beef9-2513-474a-9cb7-6c32a97ecee3-1
    buy-btc-banner
    ee4beef9-2513-474a-9cb7-6c32a97ecee3-1

    Download the Casa app

    App Store
    Google Play
    logo-black-x-temp
    LinkedIn
    Instagram
    YouTube
    Website
    Facebook

    Casa, Inc., 1580 N. Logan St., Ste 660, PMB 78958, Denver, CO 80203

    Manage preferences