Red Hat NPM Packages Backdoored in Supply Chain Attack

A Red Hat employee’s GitHub account was compromised, giving an attacker access to one of the most trusted namespaces on NPM — and the ability to push backdoored packages to tens of thousands of developer machines.

By Monday, 32 official Red Hat packages under the @redhat-cloud-services scope had been laced with a credential-stealing worm. The compromised versions were downloaded roughly 80,000 times per week, according to Wiz Research, which detected the attack on June 1. Most, but not all, of the affected packages had been pulled by publication time.

If your organization installed any @redhat-cloud-services package since June 1, security researchers have one word for you: rotate.

How the Attack Worked

The attacker didn’t need to break into NPM itself. Instead, they compromised a Red Hat employee’s GitHub account and pushed malicious “orphan commits” — code changes invisible to normal code review — directly into three RedHatInsights repositories. Those commits contained a GitHub Actions workflow file and an obfuscated script.

When the workflow ran, it requested a short-lived OIDC token from GitHub and used it to publish backdoored package versions through NPM’s trusted publishing system. The packages even carried valid SLSA provenance attestations — the industry’s gold standard for verifying software authenticity — making the malicious versions nearly indistinguishable from legitimate ones.

The attack unfolded in two waves on June 1, according to Wiz: the first at 10:53 UTC, the second roughly three hours later.

What the Malware Does

Each compromised package declares a preinstall script that runs automatically during npm install — before any application code executes and before the developer has any indication something is wrong.

The payload, dubbed “Miasma,” is a 4.2-megabyte JavaScript file buried under four layers of obfuscation: ROT-21 encoding, AES-128-GCM encryption, an obfuscator.io custom string table, and a custom cipher using 200,000-iteration PBKDF2 key derivation. Each layer is designed to defeat a different class of analysis tool.

Once running, Miasma performs a broad credential sweep: GitHub Actions secrets, AWS access keys, GCP and Azure credentials, HashiCorp Vault tokens, Kubernetes service accounts, npm and PyPI publish tokens, SSH private keys, Docker registry credentials, and any .env files it can find. According to StepSecurity, the malware also reads directly from GitHub Actions Runner process memory to extract secrets that never appear in logs — bypassing GitHub’s masking mechanism entirely.

It then encrypts the stolen data and exfiltrates it through GitHub’s own API, making the traffic indistinguishable from legitimate usage.

And it spreads on its own. Using harvested npm tokens, the worm republishes backdoored versions of other packages on compromised accounts, even bypassing two-factor authentication via NPM’s bypass_2fa parameter.

StepSecurity also found the malware installs persistent backdoors in developer tools: a hook in Claude Code that executes attacker code at every session start, and a VS Code task that triggers on folder open. Both survive package removal.

A Growing Campaign

Miasma is the latest variant of “Mini Shai-Hulud,” a supply chain attack framework built by threat group TeamPCP. The same tradecraft hit Bitwarden in April, SAP and PyTorch Lightning the same week, over 160 packages including Mistral and Tanstack on May 12, and Microsoft’s DurableTask on May 19. When TeamPCP published the full source code on GitHub in mid-May, it effectively armed anyone who wanted to run the same playbook.

This variant shifts focus toward cloud identity collection — not just stealing credentials, but enumerating every identity an infected machine can access. Each infection also generates a uniquely encrypted payload, rendering hash-based detection useless across versions.

Why Red Hat Matters

Red Hat is not a random target. Its enterprise Linux and cloud services underpin infrastructure at thousands of organizations — governments, banks, healthcare systems. An NPM package from @redhat-cloud-services carries implicit trust that most open-source packages never earn.

That trust is exactly what made the namespace valuable to an attacker. The supply chain’s weakest link isn’t the code. It’s the assumption that official channels are safe.

Organizations that may have installed affected packages should immediately rotate all CI/CD secrets, cloud credentials, SSH keys, and npm tokens, and audit developer workstations for persistence mechanisms.

Sources

Dozens of Red Hat packages backdoored through its official NPM channel — Ars Technica
Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm — Aikido
Multiple redhat-cloud-services npm Packages compromised — StepSecurity
Miasma: Supply Chain Attack Targeting RedHat npm Packages — Wiz

Discussion (10)

vkrishnan

The OIDC token abuse here is particularly worth studying. GitHub's trusted publishing was designed specifically to prevent unauthorized package publishes — the provenance chain is supposed to provide an unforgeable link between source and artifact. But when you compromise the repo itself through an employee account, you inherit all of that trust infrastructure. The identity confusion problem in OIDC-based supply chains was outlined in the 2024 paper from the Google OSS-Fuzz team (Zimmermann et al., "Keeping Your Supply Chain Clean"). The fundamental issue is that SLSA provenance v1.0 authenticates the build platform, not the human who triggered it. One compromised GitHub session token and the entire attestation system testifies on behalf of the attacker. This is an architectural gap that no amount of developer credential hygiene can close on its own.

18 ↑

defsec_dave

Good reference on the identity confusion angle. That problem's going to get worse — every major package registry moved to OIDC trusted publishing in the last year and they all make the same assumption that source repo integrity = author identity. One thing I haven't seen discussed much: the orphan commits technique. Those don't show up in default git log, so they're basically invisible to any review process that isn't explicitly scanning for them. That's a git design decision coming back to bite us.

9 ↑

ChadM_83

So Red Hat, the ENTERPRISE security company, got popped because one employee's GitHub account was compromised? And we're paying how much for RHEL subscriptions?

7 ↑

bluecoat99

Preinstall scripts should be opt-in. Full stop. `npm install` silently executing arbitrary code has been a known problem for a decade. Nobody wants to fix it because it breaks half the ecosystem. If you touched any of these packages: nuke your creds, check your workstations. The VS Code and Claude Code persistence mechanisms aren't going away on their own.

14 ↑

realpolitik_rc

Worth noting the regulatory dimension. The EU Cyber Resilience Act (Regulation 2024/2847, Article 13) requires manufacturers to report "anomalies in the development environment" within 24 hours of becoming aware. Red Hat qualifies as a manufacturer under CRA definitions since they distribute software with commercial elements. On the US side, CISA's Secure Software Development self-attestation requirements (per OMB M-22-18) apply to Red Hat as a federal supplier. Whether a compromised NPM namespace violates their attestation is an open question, but it should trigger notification obligations at minimum. Congress has held three hearings on software supply chain security since March. The SCuBA Act (S.3188) specifically proposes mandatory attestation for open-source dependencies in federal procurement. Incidents like this are exactly what the sponsors point to.

12 ↑

jennaw

the claude code thing is the creepiest part to me. a hook that runs every time you start a coding session?? and it survives removing the package?? how do you even check for that

3 ↑

SarahK

200,000 PBKDF2 iterations for the key derivation on the obfuscation layer is hilarious. They're literally slowing down their own malware's decryption on every execution. You can do effective obfuscation with 10k iterations and a decent cipher. These guys watched too many hacker movies. Also AES-128-GCM? In 2026? Just use 256 like everyone else.

5 ↑

anonymoose_dev

The high iteration count isn't about runtime performance — it's about making static analysis and sandbox detonation impractical. If a researcher feeds this into an automated unpacker, each layer takes significantly longer to reverse. Four layers with 200k iterations each means you're burning hours of compute just to get to the payload. The AES-128 vs 256 choice doesn't matter here either. They're not protecting state secrets. They just need the analysis to be annoying enough that most automated tools time out before completing.

11 ↑

sysadmin_mike

Has anyone else noticed this whole article reads like it was written by ChatGPT? "The supply chain's weakest link isn't the code. It's the assumption that official channels are safe." Come on. That's textbook AI-generated prose. Clean, perfectly structured, zero personality. Not saying the attack isn't real, but this "Jonny V. Nuovo" character has never written anything that sounds like a human being.

15 ↑

torontodev

Living this right now. We pulled @redhat-cloud-services/rule-components into our pipeline on June 1 around 14:30 UTC. Team's been up since 10pm rotating credentials. AWS root keys, IAM roles, GitHub PATs, npm tokens, the works. Found the preinstall hook in two developer laptops. Wiping them tomorrow. If you're in the same situation: don't sleep on the workstation angle. The CI secrets are obvious but the local persistence is easy to miss.

22 ↑