TL;DR

• A new wave of the Shai-Hulud malicious package campaign emerged on npm, with 2,225 software component versions impacted.

• The malware executes through a malicious preinstall hook, steals npm, GitHub, cloud, Kubernetes, Vault, CI/CD, and other credentials, then uses stolen publishing access to compromise additional packages.

• Organizations that installed an affected version should treat the environment as potentially compromised. Remove the malware and any persistence before revoking credentials, then rebuild from known-good components.

On August 4, 2026, Shai-Hulud re-emerged in the keyv and cacheable ecosystems on npm, quickly expanding into packages controlled by other maintainers, including packages in the @servicetitan namespace.

The affected releases use trusted packages to deliver credential-stealing malware and propagate into additional npm components. The package may be legitimate while the release is not.

What Happened?

Attackers published malicious versions of legitimate npm packages through a compromised GitHub maintainer account and additional publishing accounts reached using stolen credentials, including accounts with access to packages in the @servicetitan namespace. The affected releases contain a malicious preinstall hook that invokes setup.mjs.

Where dependency lifecycle scripts are permitted, the loader downloads a standalone Bun runtime and executes an obfuscated second-stage payload identified as Math_Symbol.js or Math_Init.js. npm 12 blocks unapproved dependency install scripts by default, but the hook can still execute in earlier npm versions or environments configured to permit it.

The package can continue working as expected while the surrounding environment is compromised. The malware searches local files, environment variables, running processes, cloud metadata services, Kubernetes service accounts, and Vault locations for npm, GitHub, cloud, CI/CD, database, SSH, payment, messaging, and other credentials.

It then encrypts and exfiltrates the collected data. When it finds usable npm publishing access, it identifies other packages controlled by the victim, injects the same malicious hook and payload, increments their versions, and republishes them.

That creates a repeatable cycle:

1. Compromise a trusted maintainer or publishing credential.

2. Publish malware through a legitimate package.

3. Steal credentials from a developer machine or CI environment.

4. Use those credentials to compromise more packages.

5. Repeat.

The use of Bun adds another layer to the execution chain and may help the payload operate beyond controls focused narrowly on Node.js. Relevant activity can include node running setup.mjs, downloads of a Bun archive, Bun executing Math_Symbol.js or Math_Init.js, temporary Bun files, and unexpected outbound traffic to npm, GitHub, cloud metadata services, or attacker-controlled infrastructure.

How Shai-Hulud Persists and Evolves

The original Shai-Hulud campaign, first observed in September 2025, demonstrated that malicious npm packages could do more than steal secrets.

This campaign follows the defining behavior of the Shai-Hulud malware family: compromise trusted packages, harvest credentials, abuse publishing access, and propagate through the open source ecosystem.

Earlier Shai-Hulud npm activity showed that malware could move beyond one-time credential theft and use stolen tokens to poison additional packages. Later Miasma waves continued to change their execution and obfuscation techniques while preserving that basic model.

Mini Shai-Hulud adds or extends several techniques, including:

• Downloading Bun to execute its second stage.

• Using separate GitHub and domain-based exfiltration channels.

• Targeting AI coding and IDE configuration.

• Establishing host-level persistence.

• Republishing compromised packages through trusted identities and workflows.

Microsoft Threat Intelligence reported a consistent infection pattern across the affected packages it examined, suggesting one actor was using multiple stolen tokens. That does not establish that every Shai-Hulud campaign comes from the same operator, but the technical lineage is difficult to miss

More Than 2,200 Affected Versions

At the time of publication, Sonatype Research Labs is tracking 2,225 component versions associated with sonatype-2026-005579.

Sonatype tracks versions because risk can differ from one release to the next. Teams need to know whether the version they actually use is affected, not simply whether the package name appears on a list.

The count is a current snapshot, not a final tally. Organizations should check their application exposure in Sonatype Guide or their software composition analysis (SCA) data rather than rely on an early static package list.

How Should Organizations Respond?

Organizations should check developer workstations, CI/CD runners, build agents, caches, container images, and related environments for affected components.

Review package.json, package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, build logs, and repository or proxy telemetry. Look for:

• setup.mjs, Math_Symbol.js, and Math_Init.js.

• Unexpected Bun binaries.

• Suspicious changes to .claude/settings.json or .vscode/tasks.json.

• Unauthorized npm releases or unusual GitHub repository activity.

If an affected version was installed, removing the package is not enough. Isolate the system, preserve relevant logs, investigate outbound activity, and remove any persistence before revoking or rotating potentially exposed npm, GitHub, cloud, Vault, Kubernetes, CI/CD, SSH, database, and service credentials.

Then rebuild from a known-clean environment using verified, uncompromised package versions. Do not assume a later version is safe simply because its number is higher.

Trust Is Still the Attack Vector

The Mini Shai-Hulud npm compromise reinforces a pattern Sonatype continues to track across npm attacks: adversaries are increasingly targeting trusted maintainers, packages, and publishing workflows rather than relying on typosquatting, dependency confusion, or suspicious new package names.

Many organizations still make software security decisions based on historical reputation:

• The package is popular.

• The maintainer is known.

• The project has existed for years.

• Previous versions were safe.

• The release includes provenance.

• The update appears to come from the normal publishing workflow.

None of those signals proves that the component being downloaded now is safe.

Security teams must verify the specific behavior of incoming component versions rather than relying on historical project trust. They also need proactive controls to intercept malicious components before they execute in developer workstations or build pipelines.

Sonatype Research Labs will continue investigating the campaign and updating sonatype-2026-005579 as additional components and technical details are confirmed. This follows Sonatype's editorial approach of leading with timely intelligence, grounding conclusions in research, and giving developers and security teams practical next steps.