NPM Supply Chain Attack: How One Email Almost Destroyed the Entire Crypto

"NPM," "supply chain attack," "frontend hijacking," "do not make any on-chain transaction"...

Waking up yesterday, the timeline was flooded with these keywords. You might have subconsciously thought it was just another hacker farce, but you didn't realize that an unprecedented "NPM supply chain attack" had quietly exploded in the dead of night.

Let's briefly summarize what happened that night: "Hackers hijacked an NPM open-source library maintainer's account and implanted malicious code. Websites that had updated the relevant libraries would automatically execute the malicious program, which would monitor and intercept transactions initiated by crypto wallets through the frontend website, tamper with transaction information, and change the recipient address to the attacker's address, thereby stealing user funds."

This was a supply chain attack targeting NPM libraries: the attackers did not directly attack your project's code, but rather the "upstream"—the third-party packages your project depends on, the accounts of these package maintainers, the publishing process, or the repository. Once the upstream is contaminated, it will spread down the dependency chain to countless downstream projects, causing widespread infection.

How did this large-scale hacker incident happen? And how did OneKey users escape it? This article will explain it to you from beginning to end 👇

The Ins and Outs of the Incident

Around 10 PM Beijing time on September 8th, a member of the cybersecurity company Aikido called out NPM maintainer qix on the social media platform bsky, stating that their account had been stolen and related open-source libraries had been maliciously updated. This was quickly confirmed by the maintainer themself.

The reason for the theft was very simple: a phishing email. The victim, qix, stated that they received an email from the NPM team asking them to update their "2FA" information, otherwise their account permissions would be frozen. After dutifully following the instructions, the hacker had already hijacked the maintainer's account and gained the authority to tamper with the code!

Afterward, the hacker continuously updated the open-source library code and released new versions. According to statistics, the affected libraries had accumulated over 2.6 billion downloads, demonstrating the wide scope of the impact.

By this time, transactions you were making on various DApp frontends might have already been targeted by the malicious program. The theft process can be briefly described as:

User initiates a transaction on the frontend -> Malicious program monitors and intercepts it in advance -> Replaces the recipient address before sending to the wallet for signing -> Submits the tampered transaction information to the wallet for signing -> Funds are sent to the hacker-controlled wallet.

You might think that when the signature is initiated and the sending address is found to be incorrect, it would be easy to avoid this "low-level attack." However, you underestimate the hacker. To make you "confidently" sign this transaction, the hacker uses an algorithm called "Levenshtein distance algorithm" to select an address very similar to your address field to replace it, thereby making you relax your vigilance.

Within 8 hours of the maintainer's account being stolen, all maliciously tampered NPM libraries were restored to normal. According to an analysis report by Security Alliance (@_SEAL_Org), this incident caused less than $50 in total theft. However, the enormous prevention costs behind it are immeasurable.

Good Luck Doesn't Mean You Don't Need to Care. This Is Absolutely Not the Last Time

This extremely small loss was only due to good luck and the quick response and cooperation of various security teams and relevant developers. This does not mean we don't need to pay attention, because this is not the first time, and it will absolutely not be the last.

In fact, the last NPM library supply chain attack happened less than a year ago...

On December 2, 2024, Solana's web3.js experienced a very similar incident. Similarly, an open-source library maintainer's account was stolen, and malicious programs were implanted, except that the hacker's goal last time was to directly steal your private key, and ultimately the hacker stole $160,000 in just 5 hours.

We also conducted a detailed analysis at the time. (https://x.com/OneKeyHQ/status/1864662134149595285)

What Did We Learn This Time?

Hardware wallets once again scored big, perfectly escaping disaster again

This attack was mainly based on malicious actions carried out in a browser environment. When users submit transaction requests on the application frontend, the hacker's malicious program takes advantage of the vulnerability to tamper with the transaction information, making users unknowingly sign incorrect information.

For hardware wallets, even if you submit a transaction on the web, all transaction information is independently transmitted to the hardware wallet and independently simulated and parsed by the hardware wallet's chip. All transaction content is then parsed into "human language," informing the user about the contract function being called, the authorized amount, the authorized address, and the contract name, achieving "what you see is what you sign," allowing clear viewing of every critical piece of information to ensure transaction security.

Supply chain attacks are hard to prevent, developer defense habits are key

Developers are human, and there are always times when they are careless. This time it was upstream code poisoning, next time it might be stealing sensitive information from development logs. In any case, if developers can implement daily preventive measures at every step of all supply chain links, the occurrence of hacker attacks can be largely avoided.

For example, in this case of permission loss leading to upstream code library contamination, downstream developers can prevent impacts on end-users by focusing on the following key points:
 - Locking package versions: Use lock files to freeze dependency versions, preventing automatic updates and the introduction of unaudited code.
 - Private registries: Set up internal mirror repositories to audit and cache public dependency libraries, avoiding direct exposure to external sources.
 - Automated security scanning: Integrate security scanning tools like Dependabot to quickly respond to dependency flaws while also conducting manual review.

To learn about complete prevention measures, please refer to OneKey's open-source hardcore prevention guide 👇
(https://x.com/OneKeyHQ/status/1900445143276413059)

If You Are a OneKey Hardware Wallet User

If you are a OneKey hardware wallet user and use it with the OneKey App, then congratulations, you will not be affected by this hacker attack because:

• OneKey's hardware wallet comes with the "SignGuard" signature parsing system. Transaction information is independently verified and parsed locally and then clearly presented to the user. All transaction content can be ensured to be authentic, and if there is any suspicious/incorrect information, the user can immediately detect it when confirming on the hardware device.
• OneKey's dependency code management uses version locking and does not update unaudited versions. Therefore, this malicious update version was not used by the OneKey team.

End

This NPM supply chain attack once again reminds us: security is not an option, it is the only option.

Countless bloody cases have proven that hardware wallets are an essential item for the crypto playground, and choosing a hardware wallet with signature parsing makes your crypto journey full of security.