The short answer
In September 2025 attackers phished an npm maintainer and pushed malicious versions of widely used packages such as chalk and debug, and a self-spreading worm called Shai-Hulud then stole developer tokens and republished infected packages. Similar waves followed into 2026, on npm and through compromised WordPress plugin update channels. Your site is exposed if it automatically pulls new versions of third-party code without checks. Lock versions, review updates and protect developer accounts.
- Supply-chain attacks poison trusted code at the source, so every site that updates gets it.
- Lockfiles, pinned versions and a short delay before adopting new releases cut exposure.
- Developer and CI tokens are the prize; protect them with two-factor and short lifetimes.
- Ask every supplier how they vet dependency updates.
What happened
On 8 September 2025 a phishing email gave attackers access to a maintainer account for packages including chalk and debug, which are downloaded billions of times a week. Malicious versions designed to hijack crypto-wallet transactions in browsers were published and removed within hours. A week later the Shai-Hulud worm began stealing npm, GitHub and cloud tokens from developer machines and using them to publish infected versions of more packages. Sources: AWS Security: chalk, debug and the Shai-Hulud worm
Why it keeps happening
Modern software is assembled from thousands of small open-source packages. Compromise one popular maintainer and the code flows into countless builds automatically. WordPress has the same pattern through plugin update servers. Researchers reported further npm worm waves and plugin-vendor compromises through 2026.
What owners should ask
Does our build use a lockfile? Are dependencies updated through reviewed pull requests rather than automatically on deploy? Who can publish to our hosting, and do they use two-factor? Are tokens in our CI pipeline scoped and rotated? How quickly would we know if a dependency was compromised?
Practical controls
Use lockfiles and pinned versions. Turn on Dependabot or Renovate so updates arrive as reviewable changes. Wait a few days before adopting brand-new releases of critical packages. Use npm’s trusted publishing and provenance where available. Keep the number of dependencies small. Sources: GitHub on securing the npm supply chain
Our verdict
You cannot avoid open source, and you should not. You can avoid pulling untested code into production. Make dependency updates deliberate.
Questions people ask
Was my website affected by Shai-Hulud?
Only if your build installed a compromised version during the exposure window. Ask your developer to check lockfile history.
Are WordPress sites exposed to supply-chain attacks?
Yes, through compromised plugin or theme updates.
Should we stop updating?
No. Unpatched code is the bigger risk. Update deliberately, with review.
No affiliate links on this page at publication. Product names link to official sites so you can check current pricing. How we work.
