Why Provenance Isn't Enough: Lessons from the Miasma npm Campaign

On June 1, 2026, someone published malicious versions of 32 packages in the official @redhat-cloud-services npm namespace. Not some typosquats or lookalikes with a swapped letter. It’s the real packages in a trusted scope, pulling between 80,000 and 117,000 downloads a week (Wiz Research advisory). Every one of those releases shipped with valid, Sigstore-signed SLSA provenance attestations. The tooling built to prove a package is trustworthy vouched for the malware.

The campaign was named Miasma: The Spreading Blight, and it deserves a close look, because it breaks a mental model many teams rely on: the idea that provenance verification settles the trust question.

 

How a trust signal became a delivery mechanism

The chain started far from npm. According to threat intelligence cited in incident reporting, a Red Hat employee's GitHub credentials had been sitting in commercial infostealer logs since April 13, 2026, roughly seven weeks before the attack. With that account, the attacker pushed orphan commits into three repositories in the RedHatInsights GitHub organization, bypassing branch protections and code review entirely.

Those repositories ran GitHub Actions workflows that trigger on push and request an OIDC token with id-token: write permission. The workflow exchanged that token for npm publish rights, built the poisoned packages, and published them through completely legitimate infrastructure. 

Because the build ran where it was supposed to run, Sigstore signed the attestations and the releases carried valid SLSA provenance. OIDC trusted publishing was designed to eliminate long-lived npm tokens as a risk. In this incident it functioned as an on-demand mint for short-lived, fully valid publishing credentials.

Provenance answers one question: was this artifact built by the expected pipeline from the expected repository? It says nothing about whether the commit that fed the pipeline was authorized, or whether the resulting code is safe. Miasma passed the first check because the attacker compromised the thing standing before it.

 

What the payload actually did

Each malicious release carried a weaponized package.json with a preinstall hook pointing at an index.js of roughly 4.2 MB, obfuscated through several layers of eval() and ROT-based encoding (Wiz analysis). The moment npm install resolved any affected version, directly or through a transitive dependency, the implant executed and swept the environment for GitHub tokens, npm credentials, and cloud identities across AWS, GCP, and Azure.

Stolen npm OIDC tokens were used to republish the implant into other packages the victim maintained, seeding the next wave (Snyk incident write-up). And the blast radius math is worse than the download counter suggests: these are build-time dependencies for an enterprise console, so most installs happen on developer workstations and CI runners, exactly the machines richest in long-lived secrets.

Miasma is a rebranded variant of Mini Shai-Hulud, the worm framework behind the npm campaigns of late 2025, which TeamPCP open-sourced in May 2026. Once the toolkit went public, the barrier to running a campaign like this dropped to owning one maintainer identity. Three days later, Wiz documented a second wave abusing binding.gyp instead of preinstall scripts to reach execution during installation. The delivery detail changes; the pattern holds. We covered how this pattern evolved through 2024 and 2025 in 11 Examples of Supply Chain Attacks, and Miasma reads like its logical next chapter.

 

What actually catches this class of attack

Provenance verification stays useful, and nothing here argues for dropping it. The lesson is about what has to sit next to it.

Install-time script scrutiny
The payload ran during installation, before any application code was ever imported. An SCA process that flags new or changed preinstall, postinstall, and native build hooks in dependency updates catches the exact mechanism both Miasma waves used. A newly added install hook in a patch release of a frontend component library is a loud anomaly.

Behavioral and content analysis of the artifact itself
A 4.2 MB obfuscated blob with eval chains inside an API client package is detectable on content, regardless of who signed the build. This is where analyzing what shipped beats verifying how it shipped. The same logic applies one level up: when a dependency arrives only as a compiled or minified artifact, binary analysis inspects what the package actually contains rather than what its metadata claims.

Reachability-aware dependency management
After an incident like this, the first operational question is which projects actually pull the affected packages and whether the malicious code path executes in each environment. Teams that maintain a live dependency inventory with reachability analysis answered that in hours. Teams that reconstruct dependency trees by hand answered it in days, during which the worm kept spreading.

An adoption cooldown
Both Miasma waves were disclosed and revoked within hours. An install-age policy that delays adopting freshly published versions by even a few days would have kept most environments outside the exposure window entirely.

 

Trust the process, verify the contents

The supply chain security stack of the last few years, provenance, attestations, trusted publishing, was built to answer identity questions: who built this, where, from what commit. Miasma demonstrates that an attacker who takes over the identity inherits all the trust attached to it. Content questions need their own answer: what does this package do at install time, what does it reach for, what did the new version add.

DerScanner's SCA was built for the content side of that equation, and run entirely inside the perimeter, so the dependency inventory never leaves the building. If the dependency graph currently gets trusted on signatures alone, a demo is a practical way to see what content-level analysis flags in a real project.