The largest software supply chain attack in history - Integrity Technologies
Apply Now

The largest software supply chain attack in history

What happened: a software “poisoning” attack on NPM

In early September 2025, security researchers uncovered a coordinated attack on the NPM ecosystem — the central library repository where millions of developers get pieces of code (packages) to build websites and apps. Palo Alto Networks+2www.trendmicro.com+2

Rather than attacking one website or company, the hackers compromised trusted NPM packages. These packages were used by many applications. The attackers sneaked malicious code into them, so that when developers installed or updated the package, the malware also got installed — hidden in plain sight. www.trendmicro.com+3Palo Alto Networks+3StepSecurity+3

One malicious piece of malware in this campaign is called “Shai-Hulud”, a self-replicating worm that can spread automatically through package dependencies. www.trendmicro.com+4Unit 42+4StepSecurity+4

How it worked — in simple terms

Think of your application like a house made of Lego blocks. Many of those blocks aren’t built by you — you import them (e.g. a button component, a logging tool, a UI widget). NPM is like the warehouse of Lego blocks; when you build your house, you fetch certain blocks (packages) from that warehouse.

In this attack, hackers didn’t break into your house directly. Instead, they compromised the warehouse (or some specific Lego blocks inside it). They changed some blocks so that each time someone took them, the blocks carried a hidden trap (malicious code).

Here are the steps they used:

  1. Phishing to gain access
    They tricked (phished) one or more package maintainers via fake messages claiming to be NPM support, prompting them to “reset” their two-factor authentication (2FA). As a result, the attackers captured both login credentials and valid 2FA tokens. CISA+3upwind.io+3www.trendmicro.com+3

  2. Injecting malware into the package
    Once inside, the attacker published a “tainted” version of popular packages (such as debug, chalk, and other packages) with hidden code. StepSecurity+3Palo Alto Networks+3www.trendmicro.com+3

  3. Worm-like spreading and theft
    The malicious code did multiple things:

    • It scanned for sensitive data (like tokens, credentials, API keys) on developer machines or build systems. Unit 42+2StepSecurity+2

    • It then sent that stolen data to servers controlled by the attacker. Unit 42+2Palo Alto Networks+2

    • It also used the compromised credentials to further infect other packages owned by the same maintainer, republish them, thus spreading the worm deeper into the supply chain. Unit 42+2Palo Alto Networks+2

Because thousands of applications (or businesses) depend (directly or indirectly) on those packages, the impact could ripple widely.

Why it’s dangerous — beyond just “code was infected”

  • Silent infiltration — Developers depend on trusted packages. We tend to believe that what we fetch from NPM is safe. This attack breaks that trust.

  • Credential theft — Hackers weren’t just content to plant malicious code. They aimed to harvest credentials (cloud, GitHub, API keys) that could give them deep access into cloud environments, corporate systems, or other high-value targets. Unit 42+1

  • Automatic spread — Because of the worm-like mechanism, even packages not directly targeted could get infected downstream. That amplifies the scale. Unit 42+2StepSecurity+2

  • Financial risk — For organizations running critical apps, the breach could expose customer data, intellectual property, or operational systems. For crypto wallets or blockchain apps in particular, there was a threat that the malicious code might intercept or reroute transactions. Palo Alto Networks+3Dynamis LLP+3www.trendmicro.com+3

  • Trust erosion in open source — Many businesses rely heavily on open-source libraries. Attacks like this feed skepticism and call for increased scrutiny of every dependency.

What your organization should do now

Here’s a simplified action plan you (or your IT team) should consider:

  1. Audit your dependencies

    • Look at your package-lock.json, yarn.lock or similar dependency files. See if you or your projects pulled any of the affected packages around the time of the attack. CISA+1

    • Treat nested dependencies too — even if package A brings in package B which is tainted, you’re affected indirectly. CISA+1

  2. Roll back / pin to safe versions
    If a package was compromised, revert to a clean version (released before the attack) and “pin” your dependencies so they don’t auto-upgrade to a dangerous version. CISA+2Palo Alto Networks+2

  3. Rotate credentials
    Any developer accounts, API keys, cloud secrets, GitHub tokens — treat them as potentially exposed and rotate them. CISA+2Unit 42+2

  4. Enforce strong MFA (two-factor) and phishing resistance
    Use hardware-based or phishing-resistant 2FA methods. Ensure that even if someone is tricked, attackers can’t easily bypass account protections. CISA+1

  5. Monitor outbound traffic
    Watch for unusual connections from your build servers or dev environments to suspicious external domains. That may indicate exfiltration in progress. CISA+1

  6. Use software supply chain protection tools
    Tools like SBOM (software bill of materials), dependency scanners, integrity checks, and automatic alerts for unusual package versions help. Unit 42+3Palo Alto Networks+3www.trendmicro.com+3

This NPM hack is a wake-up moment for every business, developer, and organization that relies on open-source software. When the foundation is poisoned, it doesn’t matter how secure your surface defenses are — the malware may already be inside. If you want help scanning your dependencies or securing your supply chain, we can assist.

Image by Abderrahman Bensalah from Pixabay