By Mike Reinhart, Head of Network Research

TL;DR

  • A recent phishing attack caused many NPM (Node Package Manager) packages to be compromised with malicious code targeting crypto users.
  • Fortunately, it appears that a large-scale theft of digital assets did not occur.
  • Given the nature of the attack, however, it serves as an important reminder for crypto users to take security seriously and utilize extra precautions for protecting digital assets.

What Happened?

On September 8, 2025, reports of a NPM package developer being compromised began circulating. This was quickly picked up in crypto circles, as the attacker misused the developer’s account to publish malicious versions of popular NPM packages, which in turn could then be used to steal digital assets.

Specifically, the NPM packages believed to be compromised include chalk, strip-ansi, color-convert, color-name, is-core-module, error-ex, simple-swizzle, and has-ansi. A growing list has been assembled here.

Notably, none of these packages have a crypto focus, and, reportedly, the codebases for individual projects were not directly targeted. Instead, the wide usage of these packages means they are highly likely to be used by some digital asset holders (e.g. as dependencies on often-used websites) and, as a result, might be used to trick them into signing a malicious transaction.

Fortunately, this attack seemingly did not result in a large amount of stolen digital assets.

What’s the nature of the attack? How did it work?

There are a few mechanisms that appear to be at play in this attack. At a high level, a malicious package could be used to inject new code into someone’s web browser, which changes the webpage and its behavior to trick the user.

The first attack vector is to quietly change crypto addresses on a webpage to the attacker’s. Then, the malicious code listens to requests made by the webpage; checks if an Ethereum, Solana, Tron, Litecoin, or Bitcoin Cash address is present; and, if so, swaps in a malicious address that is most similar to the intercepted, correct address (here’s a list of addresses associated with this attacker). An unsuspecting user could then transfer digital assets to the attacker’s wallet without realizing it.

The second attack vector begins by checking for website components used by browser wallet extensions. If a relevant extension is found, the malicious code waits for the user to create a transfer, intercepts the generated transaction before the user is prompted to sign it, and replaces the recipient of the transfer with an attacker’s address. Unless the user carefully inspects the entire destination address when signing to ensure it matches the intended address, they could accidentally sign the transfer to the malicious wallet. This is likely true even when using a hardware wallet, such as a Ledger.

What can I do?

At this juncture, suggested best practices often include:

  1. Use a hardware wallet, such as a Ledger device. As noted above, this may not be a silver bullet. But, while browsers and their extensions may be manipulated to show anything, a hardware wallet’s screen cannot be manipulated. You can be confident that you are signing what you see there.
  2. Verify every character of addresses before signing. As attacker tradecraft has become more sophisticated, we suggest reviewing the entire address, as an attack may have generated an address with the same starting and ending characters as the intended address.
  3. Start with a test transaction before sending digital assets. In each vector used by this NPM attack, a test transfer would likely catch that digital assets didn’t end up where intended, which is a sign that something might not be right.

Also, depending on the circumstances, consider reaching out to Unit 410 👇

Unit 410 self-custody wallets were not impacted

While many self-custody products rely on web browsers or hot wallets when signing (even within multisigs), Unit 410’s unique, proprietary design for self-custody wallets:

  1. Signs offline (cold) using protected code paths that are carefully curated;
  2. Moves mission-critical elements outside browsers, where many attack vectors tend to exist; and
  3. Supports multi-party verification and automated checks helping to ensure the addresses used are known and secure.

Beyond that, we take security seriously. For example, in any cases where an external library must be used, we often pin versions so we do not automatically pull updates that might be malicious.

All of the above are big reasons why our clients use Unit 410 to support their self-custody needs, particularly when dealing with high-value positions in bleeding-edge projects.

We’re here to chat

At Unit 410, security isn’t just a feature - it’s the foundation of everything we build. Our institutional-grade self-custody solutions utilize cryptographically-secured offline storage, helping clients protect their digital assets against sophisticated attack scenarios. Public company, venture capital, and foundation leaders have chosen Unit 410’s security infrastructure to support their high-value self-custody since 2018.

And, if you love security and are interested in contributing to cutting-edge solutions for digital asset wallets and infrastructure, reach out! We are hiring!