Packages containing malicious code were recently pushed to npm. There were 18 affected packages in total, all of which are widely used. Listed alongside their downloads per week, these packages include: 

• ansi-regex (243.64 million)
• supports-color (287.1 million)
• strip-ansi (261.17 million)
• color-string (27.48 million)
• error-ex (47.17 million)
• color-name (191.71 million)
• is-arrayish (73.8 million)
• slice-ansi (59.8 million)
• color-convert (193.5 million)
• chalk (299.99 million)
• debug (357.6 million)
• ansi-styles (371.41 million)
• has-ansi (12.1 million)
• simple-swizzle (26.26 million)
• backslash (0.26 million)
• chalk-template (3.9 million)
• supports-hyperlinks (19.2 million)
• wrap-ansi (197.99 million)

In total, these packages have more than 2 billion downloads each week. 

According to a Bluesky post, a maintainer was compromised by a convincing phishing email that prompted him to update his two-factor authentication credentials. 

Below, security leaders discuss this attack and its implications. 

Security Leaders Weigh In 

Jonathan Gill, CEO of Panaseer:

As a central hub for modern software, nearly every company with an online presence will depend on npm, often without realizing. Any compromise’s impact will spread far and wide, making a breach like this seem especially alarming.

To avoid feeling overwhelmed by attacks which expose not just one company but entire ecosystems, security teams need to focus on what they can and can’t control. They can’t control the outer circle: the attackers, the security posture of your suppliers, or the unknown flaws in third-party code.

But they can control the inner circle: their own assets and security controls, and their effectiveness. Maximizing visibility into what’s knowable — e.g. infrastructure, privileged access points, security configurations, and patching status — helps to better manage the unknowable threats outside the perimeter.

Real resilience comes from proof, meaning verifiable data, not checkboxes. Organizations that master their inner circle gain the clarity, agility, and confidence to respond effectively to the next supply chain attack.

Ensar Seker, CISO at SOCRadar:

This incident represents a watershed moment in software supply chain security. The compromise of npm packages with over 2.6 billion weekly downloads highlights just how devastating upstream attacks can be when they exploit the foundational trust built into open-source ecosystems. Attackers didn’t need to break into servers or bypass technical defenses; they simply hijacked a legitimate maintainer’s account through a targeted phishing campaign. That alone granted them the keys to a vast software kingdom.

What’s particularly dangerous here is how the attackers used a domain that convincingly mimicked a legitimate one, npmjs.help, to socially engineer the maintainer. This wasn’t a spray-and-pray phishing attempt. It was calculated, timed, and executed with a deep understanding of developer psychology. The fear-based tactic of threatening to lock accounts by a specific deadline added urgency, increasing the chance of a successful compromise.

Once inside, the attackers tampered with highly popular libraries like chalk and debug, which are ubiquitous in front-end and back-end stacks across the world. These libraries are not surface-level tools; they sit deep in dependency trees, often pulled into projects silently via transitive dependencies. That’s what makes this breach so insidious. Developers and CI/CD pipelines rarely question dependencies that come pre-vetted from trusted registries. Malicious code embedded in these packages can bypass traditional static security checks and propagate downstream at incredible scale.

The software industry is facing a reality where dependency hygiene is no longer optional. When a single compromised maintainer account can poison a global software supply chain, organizations must rethink what software trust means. This starts with strong identity protection for maintainers, including mandatory hardware-based two-factor authentication, anomaly detection, and continuous monitoring of commit behaviors.

Organizations must also start treating their dependency trees as living assets that require governance, not just during development but throughout the entire software lifecycle. A software bill of materials (SBOM) is now essential. It’s no longer enough to know what code you wrote, you need to know what you inherited. Continuous validation of the packages that flow into build pipelines, coupled with deterministic dependency resolution and runtime behavior monitoring, is critical for defense.

This event also underscores a broader issue. We often assume open-source software is secure because it’s open, but that openness means nothing if identity controls are weak, if changes go unreviewed, and if package provenance isn’t verified. Security must now follow the code from origin to runtime, not just within corporate networks, but across global ecosystems.

I believe we will see more targeted phishing attacks against popular open-source maintainers in the future. This won’t be the last time. The question is how fast our tooling, our governance, and our development practices can adapt to match the evolving threat landscape.

Roger Grimes, Data-Driven Defense Evangelist at KnowBe4:

Is this the thousandth time npm packages have been compromised this decade? What’s the over/under on that number? Can’t be that much. The idea that maintainers are still not using phishing-resistant multi-factor authentication (MFA) to protect their maintainer accounts is so, so not understandable. Cybercriminals want to compromise npms and do so all the time. And yet, maintainer after maintainer don't get and use phishing-resistant MFA! It's like almost asking to be hacked. 

I’m going to put most of the blame on the majority of the cybersecurity industry that tells people they must use MFA and doesn’t tell them that 85% to 95% of the MFA being used is as phish-able as the extremely hackable login name and password they replaced with their weak MFA. And to every cybersecurity expert and guide that says, “You should be using MFA” and not “You must be using phishing-resistant MFA,” you’re doing a huge disservice to your congregation. You are contributing to the problem. Both need to change their ways.