In September 2025 attackers poisoned some of the most widely used packages on npm, the public registry almost every modern web app is built from. This is a software supply-chain attack: rather than break into your company, attackers compromise code you depend on. In the worst of them, the Shai-Hulud worm, the prize was developers' cloud and GitHub keys.
Below: the two biggest npm supply-chain incidents, why they matter even if you've never heard of npm, and a checklist to protect your product. Much of it belongs in your build pipeline, which our CI/CD pipelines service sets up with reproducible builds and least-privilege secrets.
What happened in the 2025 npm attacks
September 2025: Chalk, Debug and 16 other packages
On 8 September 2025, an attacker phished the npm account of a well-known maintainer and published malicious versions of 18 widely used packages, including chalk and debug: small utilities that sit deep inside a huge number of projects. Together they are downloaded billions of times a week.
The injected code tried to intercept and redirect cryptocurrency wallet transactions in the browser. The bad versions were removed within hours, but any project that installed during that window pulled them in automatically.
September 2025: the Shai-Hulud worm
A week later came something worse: Shai-Hulud, a self-replicating worm. When a developer installed an infected package, the malware:
- searched the machine for secrets: GitHub tokens and cloud keys for AWS, Google Cloud and Azure;
- sent them to the attackers and published them in a public GitHub repository named "Shai-Hulud";
- used the developer's own npm access to inject itself into other packages they maintained, and published those, so it spread on its own.
On 23 September 2025 the US Cybersecurity and Infrastructure Security Agency (CISA) reported that over 500 packages had been compromised. GitHub, which runs npm, removed the infected packages and blocked uploads carrying the malware's signatures. Later waves of the campaign hit hundreds more.
Why this matters to a business, not just to developers
-
Your app can be infected without anyone writing bad code. A routine
npm installon a developer laptop or build server was enough. - The target was your keys. Cloud credentials stolen from a developer machine can open your production servers, databases and customer data.
- Front-end code reaches your customers. A poisoned package in your website's JavaScript runs in your visitors' browsers, as the Chalk attack tried to exploit.
- It's not a one-off. One widely used package reaches thousands of victims at once, so attackers will keep trying.
What changed afterwards
GitHub then announced a plan to tighten npm publishing, including:
- publishing only through 2FA-protected local publishing, short-lived granular tokens or trusted publishing;
- deprecating legacy classic tokens;
- moving from authenticator-app codes (TOTP) to phishing-resistant FIDO-based 2FA;
- expanding trusted publishing, which publishes straight from CI with short-lived OIDC credentials instead of long-lived tokens.
These changes make maintainer accounts harder to hijack. Every team still has to protect its own projects.
How to protect your app from npm supply-chain attacks
For every project
- [ ] Commit your lockfile (
package-lock.json,pnpm-lock.yamloryarn.lock) and install from it in CI (npm ci,pnpm install --frozen-lockfile). Builds should never quietly pick up a newer version. - [ ] Don't upgrade dependencies the moment they're released. Most malicious versions are caught within hours or days. Renovate and Dependabot can wait a few days before proposing one.
- [ ] Review install scripts. Many attacks run during installation; pnpm, for example, can block dependency lifecycle scripts unless you allow them.
- [ ] Turn on automated alerts: Dependabot security updates and GitHub secret scanning cost nothing on most plans.
- [ ] Remove what you don't use. Every dependency is attack surface; audit them once or twice a year.
For developer machines and CI
- [ ] Use phishing-resistant 2FA (security keys or passkeys) on GitHub, npm and your cloud console. CISA specifically recommends this.
- [ ] Keep long-lived secrets off laptops. Use short-lived credentials (such as AWS SSO sessions), not permanent access keys in config files.
- [ ] Give CI only what it needs. A build job that runs tests shouldn't hold production deployment keys.
- [ ] Use trusted publishing if you publish packages yourself, so there's no npm token to steal.
If you think you were affected
CISA's guidance, summarised:
- Check your lockfiles (including nested dependencies) and cached packages against published lists of compromised versions.
- Pin to known-good versions.
- Rotate every credential a developer or CI machine could have exposed: GitHub tokens, npm tokens, cloud keys, API keys.
- Review GitHub for unexpected repositories, workflows, apps, webhooks or secrets.
- Check network logs for connections to unfamiliar endpoints.
Questions to ask whoever builds your software
If an agency or freelancer maintains your product, these five questions reveal a lot (for the wider hiring decision, see choosing a dedicated developer or an agency):
- Do you install from a committed lockfile in every build?
- How quickly do you adopt new dependency versions, and how do you review them?
- Who has npm, GitHub and cloud access, and is it protected with phishing-resistant 2FA?
- Where are our production secrets stored, and who or what can read them?
- If a dependency we use is compromised tomorrow, how would we find out, and what would you do?
Good answers are short and specific; vague ones are a reason to dig deeper.
The bottom line
Open-source packages are still the right way to build software; nobody should write their own date library. But the 2025 incidents made the supply chain a primary target. Lock your versions, slow down upgrades, protect developer credentials and make sure someone is watching: cheap habits that turn a potential breach into a non-event. Built your app with an AI tool? Our checklist for vibe-coded apps covers the other gaps.
Not sure how exposed your project is? Book a free consultation and we'll go through your build setup with you.
Frequently asked questions
What was the Shai-Hulud worm?
Self-replicating malware that spread through npm in September 2025. It stole GitHub tokens and cloud keys from developer machines, published them in public GitHub repositories, and used the victim's npm access to infect their other packages. CISA reported over 500 packages compromised.
How do I prevent npm supply-chain attacks?
Install from a committed lockfile in CI, wait a few days before adopting new versions, block unapproved install scripts, use phishing-resistant 2FA on GitHub, npm and your cloud console, and keep long-lived secrets off laptops.
What is npm trusted publishing?
It lets a package be published straight from a CI system using short-lived OIDC credentials instead of a long-lived npm token. With no stored token, there is nothing to steal.
Sources
- CISA, "Widespread Supply Chain Compromise Impacting npm Ecosystem" (23 September 2025): https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
- GitHub Blog, "Our plan for a more secure npm supply chain" (22 September 2025): https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/
- AWS Security Blog, defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm: https://aws.amazon.com/blogs/security/defending-against-supply-chain-attacks-like-chalk-debug-and-the-shai-hulud-worm
- Trend Micro, "What We Know About the NPM Supply Chain Attack": https://www.trendmicro.com/en_us/research/25/i/npm-supply-chain-attack.html
- ReversingLabs, "Shai-Hulud npm supply chain attack: What you need to know": https://www.reversinglabs.com/blog/shai-hulud-worm-npm
Originally published on znovastudio.com.
Top comments (0)