← Tools I Use

The Red Hat npm Supply-Chain Attack: What Actually Happened, and What to Do About It

2026-06-01 · ~6 min read · Conor Dobbs

On June 1, 2026, Wiz Research flagged that the @redhat-cloud-services npm namespace had been compromised. At least 32 package releases under that trusted, official scope were quietly republished with a malicious install-time payload. The affected packages pull roughly 80,000 downloads a week between them, so this is not a typo-squat on a package nobody installs — it's a hijack of a name developers already trust and pin in their lockfiles.

Researchers named the payload Miasma, a new strain in the Shai-Hulud family of npm worms that has been chewing through the registry all year. I build small developer tools and run coding agents that npm install all day long, so a credential-stealer that fires during installation is exactly the failure mode that keeps me reading these postmortems instead of skimming them. Here's the honest breakdown.

What actually happened

The attackers didn't guess a password. According to Wiz, they got into a Red Hat employee's GitHub account and used it to inject malware through the project's GitHub Actions workflows. Those workflows had id-token: write permission, which let the pipeline request a short-lived OIDC token and publish to npm as the legitimate owner. The publish came from the real CI system, with the real identity. No leaked npm token required.

The malicious versions shipped a heavily obfuscated _index.js that ran at install time via a preinstall script. The moment you ran npm install on a project that pulled a poisoned version, the payload executed on your machine or in your build — before any of your own code ran.

What it steals

Miasma is a broad credential sweep, and the target list reads like an inventory of everything a developer machine touches:

It doesn't propagate over the network like a classic worm. It spreads the way the registry itself spreads: it harvests the publish tokens it finds, uses them to poison more packages, and waits for the next developer's install to do the work. Every compromised CI pipeline becomes a new launch point.

The part you should actually be scared of

Here's the detail that I think matters more than the credential list: the malicious releases carried valid SLSA provenance attestations.

Provenance is the thing we've all been told to trust. It's the cryptographic receipt that says "this package was built by this pipeline from this commit." It is genuinely good security infrastructure. But provenance proves a build happened in a given pipeline — it does not prove the pipeline wasn't owned. When the attacker is publishing through the legitimate CI identity, the attestation is real, the signature checks out, and "verify provenance" waves it straight through.

So the lesson isn't "provenance is useless." It's narrower and more uncomfortable: provenance moves the trust boundary to your CI/CD identity, and most teams have spent far less effort securing a GitHub Actions OIDC configuration than they have securing a production database. The npm registry was never the soft spot. The soft spot was a single developer's GitHub account and a workflow with token-minting permission.

What to do about it

For this specific incident, the affected versions had largely been revoked by the time it went public, and Red Hat has stated that none of the compromised package versions were used in any shipped Red Hat product. But "the bad versions are gone" is not the same as "your machine is clean." If you installed anything from @redhat-cloud-services in the last few days — especially in CI — treat it as exposed and rotate:

The bigger pattern

This is the third or fourth npm namespace this year to fall the same way — axios, TanStack, and now Red Hat's cloud-services scope all got hit through a compromised maintainer identity rather than a flaw in npm. The registry keeps doing its job. The accounts that publish to it keep being the weak link.

The takeaway I keep landing on: supply-chain security in 2026 is identity security wearing a different hat. Your dependency graph is exactly as trustworthy as the least-protected GitHub account with publish rights to anything you install. Provenance, lockfiles, and SBOMs are all worth having — but they're guardrails around a trust decision, not a replacement for it. The teams that came through this fine are the ones who'd already decided their CI tokens were as sensitive as their production database password, because in an attack like this, they are.

Sources

← More tools I actually use

Related reading