Over 600 npm package versions hit in Mini Shai-Hulud supply chain attack

A new Mini Shai-Hulud supply chain attack has compromised hundreds of npm package versions, putting developer machines and CI/CD environments at risk of credential theft.

Security researchers tracked the latest wave on May 19, 2026, with the heaviest activity tied to the @antv package ecosystem. The attack also affected other packages and scopes, including @lint-md, @openclaw-cn, @starmind, echarts-for-react, timeago.js, size-sensor, and canvas-nest.js.

The campaign matters because the malware does not only target local files. It searches for GitHub tokens, npm tokens, cloud credentials, Kubernetes secrets, Vault tokens, SSH keys, Docker authentication files, and database connection strings. If it finds usable publishing tokens, it can also attempt to spread to more packages.

What happened in the npm attack

Socket reported 639 compromised package versions across 323 unique packages in the May 19 wave. The malicious publishing activity was concentrated in a short UTC window, which suggests automated publishing through a compromised maintainer account or token.

Snyk reported that the compromised npm maintainer account maintained hundreds of packages. Its analysis said malicious versions were pushed in rapid waves and that the affected packages collectively represented about 16 million weekly downloads.

Endor Labs said it first detected a smaller set of malicious packages and later identified hundreds more. Its research also pointed to dormant packages, including jest-canvas-mock and size-sensor, as early indicators in the campaign.

Item	Details
Campaign	Mini Shai-Hulud
Main registry affected	npm
Latest major wave	May 19, 2026
Reported scale	639 compromised versions across 323 unique packages, according to Socket
Main affected ecosystem	@antv data visualization packages and related packages
Main risk	Credential theft, cloud secret harvesting, and worm-like propagation

How the malware works

The compromised packages included an install-time payload. In many cases, the package.json file was modified to add a preinstall script that runs a root-level index.js file through Bun.

That matters because npm lifecycle scripts can run automatically during installation. A developer or build system may trigger the payload just by installing or updating a dependency that resolves to a malicious version.

Researchers said the payload used heavy JavaScript obfuscation to hide its behavior. Once active, it searched for secrets across developer workstations, environment variables, and CI/CD runners.

• GitHub and npm tokens
• AWS, Azure, and Google Cloud credentials
• Kubernetes configuration and service account material
• Vault tokens
• SSH keys and private keys
• Docker authentication files
• Database connection strings
• CI/CD platform secrets

Why the Sigstore behavior is important

One of the most concerning findings involves provenance. Endor Labs said this wave can request valid Sigstore certificates and transparency log entries when it propagates to other packages.

This does not mean the package is safe. It means the attacker can abuse the build and publishing chain in a way that still produces provenance metadata. Developers and security teams should not treat a green provenance indicator as proof that a package update was authorized.

The better signal is behavior. A package with a long publication gap that suddenly adds lifecycle hooks, GitHub-sourced optional dependencies, or obfuscated install-time code deserves immediate review.

Affected packages and ecosystems

The strongest activity centered on @antv, a data visualization ecosystem used in dashboards, graph tools, mapping tools, and React components. Related non-scoped packages were also affected.

Examples reported by researchers include @antv/g2, @antv/g6, @antv/x6, @antv/l7, @antv/s2, @antv/f2, @antv/g, @antv/g2plot, @antv/graphin, @antv/data-set, echarts-for-react, timeago.js, size-sensor, and canvas-nest.js.

Organizations should not rely only on package names in public summaries. The affected version list changed as researchers continued monitoring the campaign, so teams should compare their lockfiles and package installation history against the latest advisories from their security vendors.

Indicators security teams should check

Security teams should review developer machines, build runners, and package publishing accounts that installed affected versions on or after May 19, 2026. The safest response is to treat exposed secrets as compromised.

Indicator type	What to look for
Install script	preinstall scripts that run bun run index.js
Exfiltration endpoint	t[.]m-kosche[.]com
GitHub marker	niagA oG eW ereH :duluH-iahS
Repository pattern	Dune-themed names with result files under results/
Package behavior	Unexpected lifecycle hooks, optional GitHub dependencies, and version bumps

What developers and companies should do now

Any company that installed affected versions should start with containment. Remove suspicious package versions, preserve logs, and avoid reinstalling dependencies from a compromised state.

Credential rotation should come next. GitHub tokens, npm tokens, cloud keys, Vault tokens, Kubernetes credentials, and CI/CD secrets may need replacement if they were present on affected systems.

Teams should also review recent npm publishing activity. If a stolen npm token had publish access, the attacker may have used it to push additional malicious versions under a trusted maintainer identity.

1. Audit package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, and yarn.lock files for affected versions.
2. Pin affected dependencies to known-clean versions before the May 19 wave.
3. Run emergency installs with script execution disabled where practical, such as npm install --ignore-scripts.
4. Rotate GitHub, npm, cloud, Vault, Kubernetes, SSH, and CI/CD credentials from clean machines.
5. Search GitHub accounts for unexpected public repositories, Dune-themed names, and results/results-*.json paths.
6. Review recent package publishing logs for unauthorized version bumps.
7. Monitor Sigstore and Rekor activity for unexpected certificate issuance tied to your organization.
8. Block or alert on traffic to known malicious infrastructure, including t[.]m-kosche[.]com.

Why this attack is bigger than one package

Mini Shai-Hulud shows how quickly a supply chain attack can move when it reaches package maintainers, CI/CD systems, and publishing tokens. A single compromised token can give attackers access to a large package portfolio.

The attack also shows why companies need stronger dependency controls. Automatic updates, broad semver ranges, and trusted package names can all become risky when a legitimate maintainer account gets abused.

For developers, the practical message is clear. Check recent installs, rotate exposed credentials, and review dependency updates before trusting any package that changed during the attack window.

FAQ