New Shai-Hulud Miasma Wave Hits Hundreds of npm Packages
By Sonatype Security Research Team
7 minute read time
TL;DR
-
Sonatype Security Research is tracking a new Shai-Hulud Miasma wave with 281 malicious npm package versions that move beyond obvious preinstall and postinstall scripts in package.json.
-
This variant abuses binding.gyp to trigger execution through node-gyp during npm install and can collect developer and CI/CD data, steals credentials, validates access, and self-propagate.
-
Organizations that installed affected versions should treat impacted environments as potentially compromised, rotate credentials, verify package artifacts, and investigate follow-on activity.
Shai-Hulud has re-emerged in a campaign with 281 malicious package versions across the npm ecosystem. This latest wave is part of the campaign dubbed "Miasma: The Spreading Blight" and abuses trust in open source packages to spread through software supply chains.
What makes this wave notable is the change in execution method. Instead of relying only on obvious preinstall or postinstall scripts in package.json, this variant abuses binding.gyp, a file normally used by packages with native Node.js add-ons. The campaign collects data and credentials before, if permissions allow, publishing new malicious versions of legitimate packages.
Organizations that installed affected versions should treat impacted environments as potentially compromised. Removing the package is recommended, but may not be enough if credentials were exposed or follow-on activity occurred.
We are tracking this campaign through Sonatype Guide under sonatype-2026-003581.
What Happened
The Shai-Hulud campaign has resurfaced with a new Miasma wave affecting npm packages modified to include malicious install-time behavior.
Once executed, the malware is designed to:
-
Collect system, user, developer configuration, and CI/CD environment data.
-
Search for GitHub access tokens, package registry authentication tokens, and cloud-related secrets.
-
Validate stolen credentials and enumerate accessible repositories, services, and permission levels.
-
Use stolen maintainer credentials to create and publish malicious package artifacts.
That publishing capability allows attackers to push new malicious versions of legitimate packages and further propagate through compromised repositories, CI/CD environments, and package registries.
This is not just credential theft. It is a self-spreading supply chain attack that uses trusted development relationships as its propagation path.
Why binding.gyp Changes Detection
Most npm malware guidance has trained developers and security teams to look for suspicious lifecycle scripts such as preinstall, install, or postinstall in package.json.
That is still important, but this campaign demonstrates why it is no longer enough.
In the observed Miasma variant, malicious packages can include a small binding.gyp file that causes node-gyp rebuild to run during installation. node-gyp is a legitimate build tool used for compiling native Node.js add-ons, which means its presence may not immediately appear suspicious in isolation.
The malicious behavior comes from abusing command execution inside the binding.gyp configuration. Instead of compiling a legitimate native extension, the configuration can execute a malicious JavaScript payload during the package installation process.
The result is a quieter execution path:
-
A developer or CI job installs what appears to be a legitimate npm package version.
-
npm detects binding.gyp and invokes node-gyp rebuild.
-
The malicious binding.gyp executes the payload.
-
The payload runs before the application ever imports the package.
-
Security tools that only inspect package.json lifecycle scripts may miss the behavior.
This is the central lesson of the campaign: install-time risk is broader than install scripts.
A package can look clean at the metadata level and still execute code during installation.
Trusted Packages Are the Delivery Mechanism
This campaign reinforces a critical point: attackers do not need to convince developers to install obviously suspicious packages if they can compromise packages developers already trust.
Modern software teams rely heavily on reputation signals: a familiar package name, a legitimate maintainer, a known namespace, historical downloads, or prior approval in an internal catalog. Those signals are useful, but they are not sufficient.
A package can be safe on Monday and compromised on Tuesday. A maintainer account can be trustworthy until its token is stolen. A package version can come from a legitimate registry and still contain malicious code.
That is the attacker's advantage: assumed trust. Software teams are making more trust decisions faster than humans can realistically govern manually. Developers are accepting generated code, adding dependencies, updating packages, and shipping through automated pipelines at a pace that exceeds traditional review models.
That speed is not the problem. Ungoverned trust is.
How to Determine If You Are Affected
Organizations should investigate whether affected package versions were installed in developer environments, CI/CD pipelines, build containers, or production-adjacent systems.
Start by reviewing:
-
Dependencies and lockfiles: Search for affected packages in package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, build manifests, and container images. Lockfiles and package caches may provide the best evidence if malicious versions were only available for a limited window.
-
CI/CD logs: Look for suspicious install-time behavior, including unexpected node-gyp rebuild activity, large or obfuscated JavaScript files, Bun downloads during dependency installation, or outbound connections that do not align with a normal package install.
-
Repository configuration: Inspect for unexpected AI assistant or IDE configuration changes, including files related to Claude Code, Cursor, Gemini, VS Code, and GitHub workflows.
Because the malware targets credentials, any confirmed installation should be treated as a potential compromise of the environment in which it ran.
Assume Compromise If Malicious Versions Were Downloaded
If your organization installed an affected version, assume the environment may be compromised and begin credential rotation immediately.
Prioritize npm tokens, GitHub tokens, GitHub Actions credentials, cloud provider credentials, package registry credentials, SSH keys, and any secrets available to the affected developer machine or CI/CD runner. Review GitHub, npm, and cloud audit logs for unexpected repository access, package publishes, workflow changes, token use, or newly created repositories.
Next, remove affected package versions and ensure applications and build processes use uncompromised versions. Because this attack involves compromised versions of legitimate packages, simply approving the package name is not enough. Teams must verify the exact version and artifact.
Security teams should also audit repositories for unexpected commits or configuration files, especially under directories including:
-
.github/
-
.claude/
-
.cursor/
-
.gemini/
-
.vscode/
Where suspicious changes are found, remove them and review commit history for unauthorized activity.
Finally, investigate whether any package publishing credentials were exposed. If an attacker obtained maintainer-level access, the response must include downstream package integrity review, not just local cleanup.
Cooldown Periods Are a Temporary Fix
One practical defense against fast-moving npm compromises is a cooldown period for newly published package versions. Holding new versions for review or allowing time for malicious packages to be identified can reduce exposure to attacks that are discovered shortly after publication.
Cooldown periods and other time-based remedies help to a point. But they are not a complete defense against campaigns that compromise trusted open source projects and use legitimate package workflows to spread.
The deeper issue is structural. Organizations need continuous visibility into open source behavior, package integrity, maintainer risk, and install-time activity. They need to evaluate not just whether a package was approved in the past, but whether the specific version being introduced today shows signs of malicious activity.
That means security programs must continuously audit open source software as it enters development and build environments. They must also account for AI-assisted development workflows, where coding assistants can recommend dependencies, generate package installation commands, or interact with repository configuration.
Governance Must Be Automated
The next wave of supply chain attacks will not wait for quarterly policy reviews.
Trusted open source projects are being taken over as part of systemic campaigns. Install-time execution paths are expanding. Credential theft is feeding propagation. AI-era development workflows are creating new places for malicious configuration to hide.
Organizations cannot rely on yesterday's trust decision to protect today's build.
Every new package version is a new risk decision.
Written by Sonatype Security Research Team
Sonatype's Security Research Team is focused on bringing real-time, in-depth intelligence and actionable information about open source and third party vulnerabilities to Sonatype customers.
Explore All Posts by Sonatype Security Research TeamTags
