Two days ago, malicious JavaScript code was injected into several popular packages. These packages are so widely used that it's estimated that at least one of them is used by the vast majority of software that uses npm. We have received messages from our clients asking if they are at risk and what they can do.
The good news is that you probably don't need to take any action, as your project is unlikely to have been targeted.
What is npm?
You may have read about npm being compromised, but what does that mean? npm is the standard way to handle external JavaScript software in projects. "External" means that when you're developing a software project, you often need to use something that someone else has already created. Many times these are simple things like displaying text with colours, or more complex tasks like managing requests to external services. It doesn't make sense to rewrite the same software for the same tasks again and again. By using Free and Open-Source Software (FOSS), you can simply grab a package that does what you need. This is why today's software and websites are incredibly complex without being incredibly expensive: it's due to the reutilisation of freely available software.
This process is recursive: one piece of software may require another piece to do its job, which in turn requires a few more. In the end, any project using JavaScript can use hundreds of packages. Handling this manually is unfeasible. The industry standard is to use npm, which automatically fetches the packages, understands the dependencies (what packages are required for one package to work), and deals with this complexity. npm also stores all the required packages on a server so people can download them easily.
As a result, npm is an incredibly valuable target for malicious hackers. If you gain access to npm, you can add code that will be executed on hundreds of thousands, if not millions, of machines. This is called a supply chain attack.
Understanding the risk
The malicious code targets cryptocurrency applications, attempting to steal funds when someone uses software that includes the compromised package. What does this mean? It means that even if your site is compromised, you are safe as long as you do not deal with cryptocurrency transactions or wallets. This is because the malware steals funds by altering the destination addresses of approved transactions. If you do not approve transactions, there is nothing it can do.
But what if a user is visiting my compromised site while using a crypto wallet in another tab? This should not be a problem, as browser tabs are isolated. Your site cannot interfere with a site in another tab; this is by design, part of the web security model. Is there a way to bypass this? Well, yes, there are advanced techniques that may, in very special cases, overcome this limitation. However, it is very hard to do and often requires special circumstances, and it seems this malware is not capable of it.
The problem is mainly for sites and applications that use the compromised packages and offer crypto services: a JavaScript crypto wallet, a crypto exchange, or a website that allows sending money using cryptocurrencies like Bitcoin, Ethereum, or Litecoin.
There is a very low risk of developers having the malicious packages in their local or CI/CD systems because, well, they usually don't deal with real crypto transactions in development and testing environments.
So, if you are wondering if your site is affected, the answer is almost certainly no. If you were affected, you would surely know already.
The bad news
This isn't the first time NPM has been compromised, and it won't be the last. This means that security checks and audits are more important than ever. While cryptocurrencies are the main target for this type of malware, they aren't the only ones. Future attacks could steal login credentials, alter content, or inject cryptocurrency mining software. Web security is difficult and often overlooked. That's why you should think about improving your security, not only on the developers' side but also on your side.
On the development side, make sure you have experienced developers who understand the risks of modern web technologies. It's easy to create a website, but it's hard to make it well-structured, maintainable, secure, and performant. Adjusting HTTP headers, regularly updating software, and avoiding security breaches while coding isn't simple. In the era of AI-generated code, this is even more crucial, as AI has a tendency to inadvertently introduce security holes.
On your side, you can take actions like forcing multi-factor authentication on your sites, educating your users and editors, and generally keeping security in mind. Don't be paranoid about it, but don't forget it.
The good news
The compromised packages were available for only two hours before someone noticed the problem. A few hours later, the packages were removed from NPM. Although the compromised versions were downloaded many times during that two-hour time span, the issue was detected very quickly, and actions were taken almost immediately. The disaster was less severe than you might have expected.
I think this incident allowed the industry to experience a real threat, without, it seems, great consequences (it seems only $1000 was stolen). Hopefully, the outcome will be a boost in security measures to make the NPM environment safer for everyone.
