In the fall of 2025, a major NPM supply-chain attack exposed how fragile modern software dependencies can become – especially for crypto users and developers.
The attack targeted the JavaScript ecosystem, where millions of web and software projects rely on third-party packages. Some malicious packages were designed to interfere with cryptocurrency transactions, including by monitoring or replacing wallet addresses in browser-based flows. A later worm-like campaign, known as Shai-Hulud, went further by stealing developer and CI/CD credentials and spreading through compromised package maintainer accounts.
The immediate incident has passed, but the risk has not. As AI-assisted coding and automated exploit discovery accelerate, attackers can scan, weaponize and abuse software supply-chain weaknesses faster than before.
Not every crypto wallet was affected. Several Bitcoin-focused wallets in particular, including Nunchuk and Blockstream (Jade hardware wallet) , publicly stated that their apps were not exposed to this specific NPM attack.
One possible takeaway is that the industry’s long-standing tradeoff between security and feature breadth may become increasingly relevant. Wallets that prioritize security hardening over supporting as many assets, integrations and software dependencies as possible generally operate with lower complexity and a smaller attack surface.
As AI accelerates both software development and exploit discovery on both sides of the battlefield, minimizing complexity may increasingly prove to be one of the most effective security strategies available to users, developers and service providers alike.
What happened?
In the fall of 2025, a series of supply-chain compromises affected the JavaScript ecosystem and its package registry, NPM. Attackers gained access to trusted package maintainer accounts and published malicious updates to software libraries used by thousands of applications.
Once installed, these compromised packages could perform a variety of malicious actions, including stealing credentials, compromising developer environments, or manipulating cryptocurrency-related transactions.
Several characteristics made these incidents particularly concerning:
- Popular NPM packages are often downloaded millions of times per week.
- Modern applications frequently depend on hundreds or even thousands of third-party libraries.
- A compromise of a single trusted dependency can rapidly propagate through a large software ecosystem.
- Some malicious packages specifically targeted cryptocurrency users by attempting to modify wallet addresses or transaction data.
The lesson is simple: complexity has a security cost. Every extra dependency, integration and feature adds another piece of code that must be trusted, maintained and defended.
As attackers increasingly use automation and AI-assisted tools, keeping systems simple may become one of the strongest security advantages a wallet provider or crypto service can have.
Why is the JavaScript ecosystem such an attractive target?
Modern JavaScript development relies heavily on NPM, the package registry used by many web applications, developer tools and software projects.
A single application can depend on:
- hundreds of direct packages
- thousands of indirect dependencies
Many developers do not know every library their application ultimately loads. In weaker engineering environments, some may simply not care enough until something breaks.
That creates three major risks:
- Too many dependencies to manually review: The dependency tree is often too large for realistic line-by-line review.
- Trust by reputation: Popular packages are often assumed to be safe because “everyone uses them.”
- Automated build pipelines: CI/CD systems can pull compromised packages into applications quickly if dependency updates are not pinned, reviewed or monitored.
This is what makes NPM supply-chain attacks so dangerous. The attacker does not need to break into every target directly.
Compromising a single trusted package can be enough to reach many projects downstream.
Why is this such a dangerous threat?
Users can do everything right – and still be exposed
Most cyberattacks require the victim to make a mistake. Click a malicious link. Install infected software. Visit a fake website.
Supply-chain attacks are different.
The user may follow all recommended security practices and still become exposed because the application itself unknowingly loads compromised code from a trusted source.
Trust becomes the attack vector
Traditional security models assume that software downloaded from official sources is more trustworthy than software obtained elsewhere.
Supply-chain attacks exploit exactly that assumption.
The malicious code arrives through legitimate update mechanisms, trusted package repositories and software components that developers already use every day.
Detection is difficult
Compromised packages often appear legitimate:
- They are downloaded from official repositories.
- They may be signed or published by trusted maintainers.
- The malicious code is frequently hidden, encrypted or obfuscated.
- The affected software may continue to function normally.
As a result, compromises can remain undetected long enough to reach large numbers of users and systems.
The impact extends beyond a single application
When a widely used dependency becomes compromised, the effects can spread far beyond the original target.
A single malicious package may ultimately reach:
- websites
- browser extensions
- wallet applications
- developer tools
- internal business systems
- backend services and APIs
This is what makes supply-chain attacks a systemic risk rather than an isolated security incident.
How could a compromised package affect crypto users?
- The application loads a compromised dependency
A trusted NPM package receives a malicious update and becomes part of the application’s software stack.
- Malicious code executes inside the trusted application
Because the code is loaded by the application itself, it inherits the same permissions and trust as the rest of the software.
- Transaction data can be monitored or modified
Some malicious packages were designed to monitor cryptocurrency transactions and, under certain circumstances, attempt to replace wallet addresses with attacker-controlled addresses.
- The user approves the transaction
If the manipulation goes unnoticed and the transaction is approved, funds could be sent to an attacker-controlled address instead of the intended recipient.
- Verification on a trusted screen breaks the attack
Users who verify destination addresses on a hardware wallet screen have an opportunity to detect the manipulation before approving the transaction.
Why hardware wallet verification still matters
One reason the incident attracted attention in the wider Crypto community is that some of the malicious packages attempted to modify transaction data displayed on a computer screen.
This is exactly the type of threat hardware wallets were designed to mitigate.
Hardware wallets provide an independent verification screen
- Private keys remain inside the device.
- Transactions require confirmation on the hardware wallet itself.
- Destination addresses can be verified on a separate trusted screen.
If the computer, browser or wallet application becomes compromised, the hardware wallet can still display the actual transaction details that are about to be signed.
The remaining risk is human behavior
A hardware wallet can only protect what the user verifies. If the device displays an attacker-controlled address and the user approves without checking it, the protection mechanism has effectively been bypassed.
Why software wallets face greater exposure
Software wallets usually run on the same internet-connected device as the browser, operating system and application code that may be affected by a compromised dependency.
In many cases, the wallet interface and the code responsible for constructing or displaying transaction details share the same trust boundary.
That does not mean every software wallet is automatically unsafe. But without an independent verification screen, transaction manipulation can be harder for the user to detect.
This is especially relevant for browser-based wallets, Web3 apps and complex smart-contract interactions, where the user often has to trust what the application interface is showing.
How to reduce your risks from supply chain attacks
Supply-chain attacks cannot always be avoided by end users. But users can still limit the damage if they assume that any internet-connected device or wallet interface will eventually be exposed – especially in an age where AI-assisted threat actors can discover, weaponize and exploit vulnerabilities at unprecedented speed.
Treat hot wallets as expendable
Any device connected to the internet should be treated as potentially compromised.
That does not mean you should not use mobile wallets, browser extensions or desktop applications. They are useful tools. But they should be used for convenience and day-to-day transactions, not as long-term vaults for significant amounts of money.
Separate convenience from security
The most effective defense remains separating transaction approval from the internet-connected device.
Hardware wallets such as Blockstream Jade and Coldcard are designed around exactly this principle. Even if the computer, browser or wallet application becomes compromised, the user still has an opportunity to verify the transaction details on an independent device before approving them.
Verify what you sign
Ultimately, security devices cannot replace user attention.
A hardware wallet can only protect what the user actually verifies. If an attacker-controlled address appears on the device screen and is approved without checking, the protection mechanism has effectively been bypassed.
Check your transactions carefully
One of the more dangerous aspects of transaction-manipulation malware is that it can change what you see on your computer screen without changing what is actually happening underneath.
Before approving any transaction:
- Verify the address on your wallet screen: If you use a hardware wallet, always compare the destination address shown on the device itself with the address you intend to send funds to.
- Check more than the first and last characters: Sophisticated attackers can generate addresses that intentionally resemble the intended destination, including matching the first and last several characters. A quick visual glance is often not enough. Check the beginning, middle and end of the address before approving.
- Use a second verification channel for large transfers: For significant amounts, independently confirm the destination address with the recipient through a different communication channel before sending funds.
A few extra seconds spent verifying transaction details can prevent a costly mistake that may be impossible to reverse.
DIY self-custody vs. assisted multi-signature custody
Self-custody can work very well for individuals who understand the risks, are willing to put in the time (“proof-of-work”) and can build a disciplined setup. It is the highest self-sovereign solution and remains our preferred recommendation for users who are capable of managing it properly.
With that said, we are also aware that not everyone has the time, confidence or cybersecurity skillset to handle such a setup on their own – especially when the assets involved may represent a significant part of one’s life savings.
Avoidable errors should and must be avoided.
For larger personal holdings, family funds or business treasuries, multi-signature setups can help eliminate single points of failure by distributing approval authority across multiple devices, locations or individuals. While many experienced users build and manage such systems themselves, others prefer guidance during setup or ongoing operational support.
For larger personal holdings, who would like to have experienced guiding assistance, our in-house consulting team is ready to guide you to build a resilient setup and avoid any of the common pitfalls.
Our firm has been operating in this industry for more than a decade. During that time, we have seen – and survived – it all: “Pig butchering” investment scams, state-funded threat actors, misplaced backups, phishing attacks, lost keys, compromised devices and increasingly sophisticated cybercrime. That track record of survival, we believe, is a statement in itself.
Today, we also work closely with specialist cyber threat and intervention partners on cases involving stolen or at-risk digital assets, while continuing to monitor emerging attack patterns at the edge of the industry.
While it is entirely possible to build such a setup independently thanks to the permissionless nature of Bitcoin, there is also a class of personal holdings, family funds and business treasuries for which an assisted multi-signature setup may be appropriate.
The objective must be to reduce avoidable risks and remove single points of failure wherever practical.
A single careless mistake, one broken device or one compromised computer should not be the cause of losing access to intergenerational wealth.
Conclusion
The NPM incidents will eventually fade from memory. The lesson should not.
For decades, users were taught to avoid suspicious downloads, fake websites and obvious scams. Supply-chain attacks are so dangerous because they circumvent the obvious red flags. The software may be legitimate. The source may be official. The developers themselves may be victims.
In an increasingly complex software world, security is no longer just about avoiding bad actors. It is about reducing unnecessary trust, minimizing complexity and verifying critical actions independently.
In Bitcoin, “don’t trust, verify” applies to software too.
