In what is being called the largest supply chain attack in history, attackers have injected malware into NPM packages with over 2.6 billion weekly downloads after compromising a maintainer’s account in a phishing attack.
Yikes!
Ensar Seker, CISO at SOCRadar had this to say:
“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 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 phishable 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 (like FIDO, Yubikeys, passkeys, etc.)” you’re doing a HUGE disservice to your congregation. You are contributing to the problem. Both need to change their ways.”
This illustrates the fact that the way software is built needs to be changed. Developers need to assume that anything that they use from the open source world or anywhere else is suspect until proven otherwise. And they need to keep track of what they use so that if the worst happens, there’s a paper trail of sorts.
Like this:
Like Loading...
Related
This entry was posted on September 8, 2025 at 3:22 pm and is filed under Commentary with tags Hacked. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Hackers hijack npm packages with 2 billion weekly downloads in supply chain attack
In what is being called the largest supply chain attack in history, attackers have injected malware into NPM packages with over 2.6 billion weekly downloads after compromising a maintainer’s account in a phishing attack.
Yikes!
Ensar Seker, CISO at SOCRadar had this to say:
“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 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 phishable 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 (like FIDO, Yubikeys, passkeys, etc.)” you’re doing a HUGE disservice to your congregation. You are contributing to the problem. Both need to change their ways.”
This illustrates the fact that the way software is built needs to be changed. Developers need to assume that anything that they use from the open source world or anywhere else is suspect until proven otherwise. And they need to keep track of what they use so that if the worst happens, there’s a paper trail of sorts.
Share this:
Like this:
Related
This entry was posted on September 8, 2025 at 3:22 pm and is filed under Commentary with tags Hacked. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.