In early September 2025, the JavaScript world faced one of the most dangerous attacks in recent years. The attackers gained access to a popular developer’s account and uploaded to NPM new versions of foundational packages that contained malicious code. These packages are used billions of times each week, and the attack could have led to large-scale theft from users of cryptocurrency services.
Fortunately, because of the hackers’ mistakes and the community’s quick response, the damage was minimal. The Quickex editorial team reconstructed the timeline of events and figured out why everything ended relatively painlessly.
Track how the Bitcoin price reacts to market shocks with Quickex.
How the attack unfolded
The first to report what was happening on the evening of September 8 was Ledger’s CTO, Charles Guillaume. He warned that a well-known developer’s account had been compromised and that infected versions of tools like chalk, debug, ansi-styles, and strip-ansi had been uploaded to NPM. These packages are at the core of most web applications, so the infection threatened the entire ecosystem.
It later turned out that the hackers got access to the account via a phishing email. It mimicked a message from NPM support and led to a fake login page.
NPM (Node Package Manager) is the largest catalog of JavaScript packages, where developers publish and download ready-made code modules. For example, chalk is used for colored text formatting, debug for logging, and ansi-styles and strip-ansi for working with console control characters. When the attackers released the new versions, those releases began installing automatically into projects if developers hadn’t pinned older revisions.
As news of the attack spread, crypto projects rushed to post on their social channels that the incident hadn’t affected them.
How the malicious code worked
The embedded program acted like a crypto-clipper—a type of attack that replaces a wallet address in a transaction. A user thinks they’re sending funds to their own account or to a friend, but in fact the money goes to the attacker’s address.
StarPlatinum broke down the mechanics in detail. According to him, the code had two modes.
- In the “passive” mode, it replaced addresses right in application interfaces.
- In the “active” mode, it intercepted transactions before signing and changed the destination details.
To mask itself, it used the Levenshtein algorithm to pick the most similar strings: the first and last characters of the address matched, which made the substitution almost unnoticeable.
He also cited specific accounts the stolen funds were supposed to be sent to: the main one, 0xFc4a4858bafef54D1b1d7697bfb5c52F4c166976, and several reserve addresses.
At the time of the blogger’s post, transfers to these wallets had been recorded, but the funds remained unmoved.
Developers first learned about the problem when automated builds started failing. The logs showed unusual errors like “fetch is not defined.” A check revealed obfuscated code and suspicious functions related to Ethereum and Solana.
Why the damage was minimal
Although the idea of the attack looked dangerous, in practice it didn’t work. The code turned out to be too unstable and broke build processes. That allowed the community to quickly spot anomalies and block the infected versions.
Charles Guillaume later clarified that the attack had effectively failed: there were very few victims. According to him, the malicious code targeted crypto operations and replaced addresses directly in network responses, but due to mistakes by the developer-hackers it triggered unpredictably.
Arkham estimated that the attackers managed to steal only $159. The money arrived at the wallets that had appeared in Ledger’s reports. The amount is negligible compared to the scale of the potential risk, but the episode showed how close the ecosystem came to a serious crisis.
Balance of the attackers’ crypto wallet, according to Arkham
The role of hardware wallets
The greatest risk was to users of software wallets that sign transactions right in the browser. There, address substitution could pass almost unnoticed. The situation looked very different for those using hardware devices to store keys.
A hardware wallet shows the user all transaction details on its own screen, and confirmation happens with a physical button. Even if an application replaces the address, the device displays the real recipient. An attentive user will immediately notice the discrepancy and cancel signing.
According to Guillaume, features like Clear Signing and built-in transaction checks make hardware solutions a key barrier against such attacks.
A lesson for the crypto community
This story is a reminder that supply-chain vulnerability remains the industry’s main risk. A single developer account being compromised can put millions of users worldwide at risk.
There are three main lessons to take away from the situation:
- Developers should pin dependency versions, use reproducible builds, and carefully review updates to foundational tools.
- Crypto holders should keep assets in hardware wallets and carefully verify addresses on the device screen before every signature.
Developer accounts in the NPM ecosystem must be protected with security keys and multi-factor authentication so that phishing doesn’t lead to compromise.
Bottom line
The NPM attack showed how fragile the entire infrastructure can be: billions of installs depended on a single account. This time the damage was limited to $159, but next time it could be different.
Luck and the attackers’ mistakes are no substitute for systematic security. That’s why both developers and users should take steps so that new attacks don’t catch them off guard.
Find the best crypto exchange rate on Quickex.