Miasma npm Attack: How Sphere Caught It Before Red Hat Did

Supply chain attacks are not new. But this one hit differently. Not because of its sophistication — if anything, the method was alarmingly simple. It hit differently because the attackers did not break into Red Hat. They walked in through a door that had already been quietly unlocked for weeks.

We have seen this before. Closely.

What Happened

On June 1st, 2026, attackers began pushing backdoored versions of packages across the official @redhat-cloud-services npm namespace. These were not fake packages with typosquatted names. These were the real ones, trusted by tens of thousands of developers worldwide.

32 packages compromised. 96 backdoored versions. ~117,000 weekly downloads.

The malware, named Miasma: The Spreading Blight, is a variant of the Mini Shai-Hulud worm previously linked to threat actor group TeamPCP. It steals GitHub tokens, cloud credentials, Vault secrets, SSH keys, and npm tokens. Then it spreads — republishing backdoored versions of every package the victim account can access. One infection becomes many.

The malware executes the moment you run npm install. It does not wait for your application to start. It does not need to be imported. It runs immediately, silently, in the background.

How They Got In

The entry point was a single compromised Red Hat employee GitHub account. What followed was a precise abuse of trust — not a brute-force attack, not a zero-day. Just a structural gap exploited methodically.

Step 1 — Employee account stolen via infostealer GitHub credentials and session cookies were harvested silently. No breach notification. No alert.

Step 2 — Orphan commits pushed directly to repositories Malicious commits were pushed as "orphan" branches, completely detached from branch history, bypassing all code review and pull request requirements.

Step 3 — CI/CD pipeline weaponized via GitHub ActionsA workflow file (ci.yaml) and script (_index.js) were injected to abuse npm's trusted publishing, requesting a legitimate OIDC token to publish directly to the real @redhat-cloud-services namespace.

Step 4 — Packages published with valid provenance Because they came through the official pipeline, the backdoored packages carried valid SLSA provenance attestations. They looked completely legitimate.

Step 5 — Credentials exfiltrated to attacker-controlled GitHub repos Stolen secrets were pushed to public repositories carrying the description "Miasma: The Spreading Blight" — and the worm began propagating to every account it touched.

This is what security researchers call a confused deputy attack. The CI/CD pipeline, trusted and privileged by design, was tricked into acting on behalf of an attacker. It had the authority to publish. It used it.

Sphere Saw It First

Here is where the story becomes personal for us.

The attack did not come from nowhere. The credentials used to compromise that Red Hat employee account had already left the building — silently harvested by an infostealer and sitting in underground logs well before anyone at Red Hat knew they were gone.

On May 23rd, Sphere flagged the compromised Red Hat GitHub credential in infostealer logs — 9 days before the attack landed. The session cookie was present. The account was active. The window to act was open.

Our platform Sphere monitors dark web sources, infostealer logs, and underground marketplaces in real time. When stolen credentials surface, we surface them first — before they are used, before the damage is done.

The attack was not inevitable. The window to act was wide open — if you knew where to look.

We Have Been Here Before

This is not the first time Sphere caught something before the damage became public. It will not be the last.

Last year, Radio Televizioni Shqiptar — RTSH, Albania's national public broadcaster — had its official website and social media accounts defaced. After the attack, our team ran an investigation using Sphere. What we found was that the breach had not happened overnight.

Sphere uncovered a credential leak that had been sitting undetected for 9 months. 41 valid login credentials exposed from the rtsh.al domain. Compromised access to critical admin portals. Exposed Facebook Account Center credentials linked to RTSH's official accounts. The infostealer that harvested them had logged everything cleanly — software, host, email domain, username, password present — and moved on. Nobody at RTSH knew.

That credential leak almost certainly provided the attack pathway for the defacement. The door had been open for nine months before anyone walked through it.

The pattern is always the same. Credentials leave quietly. They sit in logs nobody is reading. Then one day, someone decides to use them.

What You Should Do Right Now

If your environment pulled any @redhat-cloud-services package on or after June 1st, 2026, do not assume you are safe. Treat the following as compromised and rotate immediately:

• All GitHub tokens and personal access tokens
• Cloud credentials (AWS, GCP, Azure — everything)
• Vault secrets and service account keys
• SSH keys on affected machines
• npm tokens and CI/CD service tokens
• Any secrets stored in environment variables during affected builds

To check if you are affected:

npm ls @redhat-cloud-services
grep -r "@redhat-cloud-services" package-lock.json

Important: deleting node_modules is not enough. The worm includes background execution mechanisms. Full credential rotation and a review of any artifacts built during the exposure window is required.

The Bigger Picture

This attack is part of a pattern. Bitwarden CLI. SAP npm packages. PyTorch Lightning. Microsoft Durable Task. Mistral. TanStack. All traced back to the same root cause — credentials that were already gone before anyone noticed.

The supply chain is not just a technical problem. It is a visibility problem. Attackers are operating in your blind spots — in infostealer logs you are not reading, in underground forums you are not monitoring, in credentials that have been live and exposed long before anyone fires a shot.

Reactive security means reading about the breach after it happens. The goal is to know before the attacker moves. That is what Sphere is built to do — and on June 1st, it did exactly that.

‍