You’re not imagining things: there have been a lot of malware attacks in the past couple months. 

Since July, there have been five high-profile attacks, and there’s no sign that it’s coming to an end. While upstream problems absolutely must be addressed, this npm Groundhog’s Day should also be a wakeup call for software producers. Similar to the way Log4j got the industry to be more diligent in addressing CVEs, it’s time to make malware a first-party citizen in application security programs.

How malware is different from CVEs

There are several types of malware described in the OWASP Open Source Top 10, with three main categories being 1) developing a malware package from scratch, 2) typosquatting/name confusion, and 3) “compromise of legitimate package” (learn more via the Risk Explorer). Malicious code can be executed on end-user systems or on systems belonging to the organization that develops and/or operates the dependent software (e.g., build systems or developer workstations). 

The fundamental difference between malware and CVEs is about intent. While a CVE is an unintentional flaw that can be exploited, malware is put there by attackers to do harm. But beyond that aspect there are three very specific differences that influence how we should handle prevention, detection, and response.

Malware has a short shelf life and is typically removed within hours

Malicious packages have very short lifespans on public registries. Once detected by security researchers or developers, they’re typically reported and removed by the registry's maintainers within hours (days at most). This quick removal is a race against time, as attackers know their window of opportunity is brief. 

A CVE, by contrast, is a documented vulnerability in a legitimate piece of software. It has a permanent identifier and exists indefinitely in databases like the National Vulnerability Database (NVD). The software with the flaw isn't removed from circulation; instead, the CVE serves as a permanent public record of the vulnerability. The solution is for the software's maintainers to release a patched version, and for users to update.

Malware seeks to compromise other systems (e.g. laptops or CI pipelines)

Although getting malware into an organization’s production environment is of high value, often malicious packages target developers and their build environments. Attackers assume that developers have privileged access to source code, internal systems, and sensitive data. And even if the developer doesn’t commit the malware to production, it can still exfiltrate data from their laptop or test environment. The attack starts at the earliest stage of development. Malware targeting developer machines aims to compromise the individual developer's system to steal credentials and sensitive data, often leveraging the preinstall or postinstall scripts in a package.json file. And attacks on CI pipelines target automated build and deployment environments with the goal of injecting malicious code into the final application or stealing secrets that the pipeline has access to.

CVEs are passive risks because they’re typically just a flaw that could be exploited. Conversely, CVEs are about the application itself, with attackers usually looking for lateral movement opportunities once they’ve achieved access. 3rd party libraries can be pulled into several parts of the SDLC (application code, containers, GitHub actions), so CVEs can be used to gain access to anywhere a dependency is running. While still a substantial risk, this is a more narrow scope than malware attacks. And unlike malware, the use of software packages with known CVEs doesn’t inherently mean you’re at risk. The majority of imported code goes unused, so if the function or package isn’t being called (i.e. is unreachable) then it’s not exploitable. Or the code with the vulnerability isn’t being used in a way that is not exposed to the conditions of the CVE (e.g., using a library with a SQL injection vulnerability, but not using uncontrolled input).

Why attackers target npm

Malware is all about scale and time. How can I hit the most people in the shortest time? Once an attacker has gained illicit access to an account (usually via phishing or other social engineering tactics), they’re on the clock to quickly insert malicious code and publish updates before the maintainer realises their mistake. 

But not all ecosystems are equally vulnerable.

JavaScript is the language of the web, and therefore is everywhere and it uses a lot of open source dependencies. Taken together, the reach is huge. It's not just that JavaScript is vulnerable, it's also probably also one of the ecosystems with the highest potential impact. This is part of what makes npm a particularly appealing target. The second reason is bad actors target ecosystems with insecure defaults that facilitate faster exploits. Unfortunately npm is where most malware gets planted because the registry hasn’t implemented prevention measures found in other language ecosystems:

• Install scripts run by default. Add a postinstall script and the malware executes on npm install.
• Token-based publishing is still the norm. Trusted Publishing exists, but isn’t enforced. Stolen credentials remain enough.
• MFA isn’t mandatory. The registry does not require maintainers to use multi-factor authentication to minimize credential theft attacks.
• Provenance isn’t mandatory. Even when packages support it, nothing requires subsequent versions to maintain that chain of trust.

Note: pnpm recently released a new setting that delays the installation of newly released dependencies (i.e. a cool-off period). This is a step in the right direction!

Let’s look at five major npm malware incidents to see how these defaults facilitated the attacks.

July 18, 2025: eslint-config-prettier

An attacker published four malicious versions of ‘eslint-config-prettier’. They executed a postinstall script that launched a Windows DLL malware via node-gyp, exploiting the package's widespread use in JavaScript tooling to maximize impact.

July 19, 2025: "is" package

Attackers published malicious versions 3.3.1 and 5.0.0 of widely-used JavaScript utility package 'is', which contained a WebSocket-based backdoor enabling remote code execution (RCE), allowing the attacker to exfiltrate sensitive data from users who installed the package.

August 26, 2025: s1ngularity Nx Attack

Attackers published malicious Nx package versions that contained post-installation malware scripts targeting sensitive developer assets, including cryptocurrency wallets, GitHub and npm tokens, and SSH keys. They also made private repositories public using stolen credentials.

September 8, 2025: Chalk & Debug Mass Compromise

Attackers pushed malicious versions to 25 popular packages, targeting cryptocurrency wallets with scripts that exfiltrated sensitive information directly from developers’ environments.

September 15, 2025: Shai-Hulud Campaign

Several packages with malicious code were published on npm, including packages from Crowdstrike and the popular npm package @ctrl/tinycolor, which has millions of downloads. So far, we have identified more than 550 affected versions from 122 distinct packages, with possibly more yet to be discovered. What makes this supply chain attack different from previous ones is that the code spreads like a virus to other packages, which get published on npm using the npm credentials of compromised developers.

Myth: You can’t be proactive about malware

While malware risk management can feel much more reactive than CVE remediation programs, there are many proactive steps you can take! 

Endpoint detection response monitoring for IoCs is probably more important for what you can do to be proactive about malware. As AppSec experts, we also focus on what application security and engineering teams can do. We covered AppSec best practices in How to Defend Against NPM Software Supply Chain Attacks - here’s a summary.

Note: we’re focused here on what you can do in the javascript ecosystem and npm because of the increased probability of malware. Other ecosystems will have different best practices.

The most effective defenses against npm supply chain attacks come from reducing what an attacker can do if they manage to compromise a maintainer account or slip a malicious dependency into your environment. Security teams should focus on hardening build pipelines and controlling how new code enters and exits their environments:

• Enforce integrity checks and pin versions in CI
• Opt out of `--ignore-scripts` rather than opting into them as a CI practice
• Integrate malware detection
• Delay package adoption for a period of time
• Reduce the number of dependencies you use

These measures help contain organizational risk. But they only work if developers also adopt safe habits when managing dependencies and accounts:

• Check in your lockfile and most importantly USE IT
• Minimize software reuse where possible
• Don’t rush updates
• Secure your npm account
• Watch for red flags

Malware detection tools must do more than just detect malware

You’ll want capabilities that support proactive and reactive measures.

Be proactive with policies that let you:

• Block the use of known malware, and packages displaying suspicious behavior but not yet reported as malware (pending investigation by the vendor’s research team) 
• Implement mandatory "cool off periods" before new versions can be used
• Identify projects without lockfiles or with unpinned dependencies
• Identify unused dependencies

From a reactive perspective, you need:

• A malware feed that updates frequently (ideally hourly)
• Timely alerts (e.g. Slack, email) about existing and new malware
• A support team that quickly notifies you of new events and aids in investigations