Mini Shai-Hulud Strikes Again: 314 npm Packages Compromised

A supply-chain attack was disclosed this week on npm, the JavaScript community's most widely used dependency manager. As reported by security firm SafeDep, an attacker group calling itself Mini Shai-Hulud planted malicious variants in 314 popular npm packages. The attack was not on a single independent developer but on the publishing credentials of the original publishers behind these packages.

The name refers to a larger Shai-Hulud campaign by the same attacker group in 2024. The previous attack used a GitHub Actions CI/CD pipeline vulnerability to compromise around 1,500 packages. Mini Shai-Hulud is the same actor's smaller but more targeted version — this time entering npm accounts through phishing of publisher access tokens.

Among the 314 affected packages are two popular categories. One group is file manipulation libraries (fs-extra plug-ins, glob variants) with weekly download bases of about 100,000. The second group consists of log and diagnostic libraries with smaller user bases but heavy enterprise use. SafeDep's analysis showed that the majority of the affected publishers used a single-token authentication mode that bypassed two-factor authentication.

The attack technique was a "postinstall" hook covertly added to the package.json file. It runs automatically when the npm install command is executed; a small script then collects environment variables from the user's system — particularly AWS_ACCESS_KEY, NPM_TOKEN, GITHUB_TOKEN and OPENAI_API_KEY — and sends them to a remote command-and-control server. The structure is not sophisticated but effective.

According to SafeDep, the campaign began around midnight UTC on 17 May and was identified 18 hours later. The compromised packages received an estimated 2.8 million new downloads during that window. The exact list of developers from whose personal environments data was exfiltrated is not yet fully known; SafeDep notified GitHub on the morning of 19 May to block the command-and-control server IPs.

npm Inc. confirmed the incident and reverted all affected packages to clean versions. At the same time, 23 publisher accounts were temporarily suspended, with account holders required to reauthenticate, enforce two-factor authentication, and rotate tokens used in the past three months. A broader policy update to all npm publishers is also expected, with a proposal to make two-factor authentication mandatory for all publishers.

Practical advice for the developer community is divided into four categories. First, rotate environment variables for any system that ran an npm install command in the past 18 hours. Second, manually diff package-lock.json files (to check for added postinstall scripts). Third, in enterprise environments, run npm install commands inside a sandbox. Fourth, use Snyk, GitHub Dependabot, or SafeDep's own supply chain analysis tool in projects.

The wider meaning of the attack lies in the JavaScript ecosystem's structural security problems. There are 3.2 million packages active on npm; if you accept that around 14% are maintained by a single publisher, a single account takeover can affect a wide user base. Since GitHub formally absorbed npm into its platform last year, security policy alignment has been more tightly tracked; but structural security still depends on the publisher's choice.

On the defence side, another important technical development is the package-signing protocol, whose adoption has grown over the past 12 months. From March 2026, GitHub has made it possible to verify packages against a publisher's signature; about 18% of npm packages currently use this signing. None of the 314 packages affected by the Mini Shai-Hulud campaign was signed.

Looking ahead, the rising frequency of these incidents in the JavaScript ecosystem — about 30-40 notable supply-chain attacks per year on npm over the past three years — points to a need for the industry to revisit the default security level of package managers. Python (PyPI), Ruby (rubygems) and Rust (crates.io) ecosystems have stricter default security policies. By comparison, npm's traditionally open policy is regarded as developer-friendly but also less secure.