Chalk and Shai-Hulud: inside the September 2025 npm supply-chain attacks

A phished maintainer and 18 poisoned packages

On 8 September 2025, an attacker phished the npm account of a well-known package maintainer and used it to publish hostile new versions of 18 widely used packages, including the utilities chalk and debug, according to a dev.to write-up of the incidents. These are small libraries, but they sit deep in the dependency trees of an enormous number of projects and together account for billions of downloads per week.

The injected code attempted to intercept and redirect cryptocurrency wallet transactions running in the browser. The tainted releases were pulled from the registry within hours, but any project that ran an install during that window received them automatically — no breach of the victim's own code or servers required.

Shai-Hulud: a worm inside the registry

Roughly a week later, a more serious threat appeared: Shai-Hulud, malware capable of spreading on its own. Once a developer installed an infected package, the worm searched the machine for secrets — GitHub tokens plus cloud credentials for AWS, Google Cloud and Azure — sent them to the attackers and published them in a public GitHub repository named 'Shai-Hulud'. It then leveraged the developer's own npm access to inject itself into other packages they maintained and republish those, producing a self-propagating chain of infections.

The US Cybersecurity and Infrastructure Security Agency (CISA) reported on 23 September 2025 that more than 500 packages had been compromised. GitHub, which operates npm, deleted the infected packages and blocked uploads matching the worm's signatures. The dev.to article notes that later waves of the campaign hit hundreds more.

GitHub's tightening of npm

In the aftermath, GitHub announced a plan to harden npm publishing:

• Allow publication only through 2FA-protected local publishing, short-lived granular tokens or trusted publishing
• Deprecate legacy classic tokens
• Shift from authenticator-app codes (TOTP) to phishing-resistant FIDO-based 2FA
• Expand trusted publishing, which pushes packages straight from CI using short-lived OIDC credentials instead of long-lived tokens

The common thread is eliminating the long-lived, phishable credentials that enabled both attacks to begin.

Hardening your own builds

Registry-level changes protect maintainers, but each team still has to defend its projects. The dev.to piece offers a practical checklist:

• Commit the lockfile (package-lock.json, pnpm-lock.yaml or yarn.lock) and install from it in CI with commands such as npm ci, so builds never silently pick up a newer release.
• Wait a few days before adopting new dependency versions; most malicious releases are caught within hours or days, and tools like Renovate and Dependabot can be configured to lag.
• Restrict install scripts, since many attacks execute during installation — pnpm, for example, can block dependency lifecycle scripts unless explicitly allowed.
• Turn on Dependabot security updates and GitHub secret scanning, which are free on most plans.
• Remove unused dependencies and audit the rest once or twice a year; every package is attack surface.
• Use phishing-resistant 2FA (security keys or passkeys) on GitHub, npm and cloud consoles, which CISA specifically recommends.
• Keep long-lived secrets off developer laptops in favour of short-lived sessions, and give CI jobs only the permissions they need — a test runner should not hold production deployment keys.

If you think you were affected

CISA's guidance, as summarised by dev.to: compare lockfiles, including nested dependencies and cached packages, against published lists of compromised versions; pin to known-good releases; rotate every credential a developer or CI machine could have exposed, covering GitHub tokens, npm tokens, cloud keys and API keys; review GitHub accounts for unexpected repositories, workflows, apps, webhooks or secrets; and check network logs for connections to unfamiliar endpoints.

Why it matters

These incidents demonstrate that an application can be compromised without anyone at the company writing or deploying bad code — a routine install on a laptop or build server was enough. The attackers' prize was credentials, and keys lifted from a developer machine can open production servers, databases and customer data. Front-end packages execute in visitors' browsers, so a poisoned dependency becomes code running on your customers' machines, exactly what the chalk attack attempted to exploit. And because one popular package reaches thousands of victims at once, the supply chain will remain a primary target. Open-source dependencies are still the sensible default — nobody should rewrite a date library — but locking versions, slowing upgrades, protecting developer credentials and monitoring what enters the build are now baseline hygiene rather than optional extras.