Red Hat NPM supply-chain attack: What to Do

The attack started Monday. Official Red Hat accounts on the npm registry were compromised and used to push a malicious worm that steals credentials and spreads to new machines, and it's still active hours later. So if your team pulled any @redhat-cloud-services package recently, you can't skip what follows.

The Attack Unfolded

The threat actor seized control of @redhat-cloud-services, a legitimate namespace inside the npm repository reserved for official Red Hat packages. Developers trust that channel implicitly. That trust was weaponized.

More than 30 packages appear to be affected. Each one carried an obfuscated payload that fires during the npm install process. Not when you run the app. Not when you import the package. The moment npm install finishes, the damage begins.

Most packages were taken down within hours. But not all. And for anyone who installed during the window, removal after the fact does not undo the exposure.

CI/CD Pipeline Compromised

The malware was published through GitHub Actions OIDC, a mechanism that uses temporary credentials for secure cloud service access. That detail matters because it points to something bigger than a stolen password. Red Hat's entire CI/CD pipeline was compromised.

How did the attacker get that deep? Very possibly through a previous supply-chain attack that infected an employee machine. One compromised laptop. One set of valid tokens. And the door swings wide open.

What Was Stolen

The worm is designed to vacuum up credentials. Not just any credentials. The good ones. Here is what is at risk on every infected machine:

• GitHub action secrets
• npm tokens
• Kubernetes configuration material
• Vault secrets
• Credentials for other cloud services

Once collected, the data gets encrypted and sent out through a web request. There is a fallback too. If the primary channel fails, the malware publishes the encrypted payload straight into a compromised GitHub repository, assuming it holds the right keys.

Red Hat issued a statement after the incident became public. The company said the packages were "strictly limited to internal development" and that "malicious code was never published for customer consumption via the console.redhat.com system." Red Hat also stated it has not identified any impact to customer or partner environments or production systems.

That is reassuring. It also misses a larger point. Internal development systems have access to things. Source code. Build pipelines. Other credentials. The blast radius from internal compromise is never zero.

The Shai-Hulud Worm

The malware has a name: Shai-Hulud. It carries all the signatures of code released last month as freely available open source. The worm does not just steal from the machine it lands on. It spreads by republishing backdoored packages to third-party accounts that the infected device can access.

One infected developer workstation with publish rights to other npm accounts turns into multiple compromised packages across multiple namespaces. That is how supply-chain fires become wildfires.

Who Is at Risk

Here is the blunt assessment that researchers are giving. Any system that installed an affected @redhat-cloud-services package version should be treated as potentially compromised. Not maybe. Not probably. Potentially compromised.

Exposure depends on installation or CI execution, not on whether you actually used the package at runtime. Npm install is enough. That means build servers, CI runners, and developer laptops are all in scope.

"Organizations should treat any system that installed one of the affected @redhat-cloud-services package versions as potentially compromised. The payload executes during npm install, before application code imports or uses the package, so exposure depends on installation or CI execution, not runtime use."

Get them now. But Socket and Aikido, two security firms tracking the incident, have published lists of affected packages and indicators of compromise, so if you've touched anything in that namespace recently, get those lists now.

The TeamPCP Connection

TeamPCP was the first group to use Shai-Hulud in the wild. The group ran a competition offering a $1,000 payout to whoever carried out the biggest supply-chain attack using the malware. Now the worm is in wider circulation among other threat groups.

That means this Red Hat NPM supply-chain attack is not a one-off. It is a playbook being distributed and repeated. The barrier to entry just collapsed.

Your Immediate Response

Monday, the attack began. If anyone on your team ran an npm install against an affected package in the past 36 hours, drop what you are doing. Start the investigation now.

Assume compromise of workstations, CI/CD pipelines, and all credentials for cloud services and repositories.

The Red Hat NPM supply-chain attack also carries a specific lesson about CI/CD hygiene that too many teams ignore. Temporary credentials are still credentials. OIDC reduces risk but does not eliminate it. If your pipeline can push packages to a public registry, treat that capability like a production secret. Because that is exactly what it is.

Lessons From Checkmarx

Checkmarx was recently hit by its own supply-chain attack. The firm failed to fully drive out the intruder on the first attempt. It was hit two more times. The initial access came from a supply-chain attack on the Trivy software developer that then pivoted to Checkmarx.

Full remediation is hard. Half measures leave doors open. The Red Hat NPM supply-chain attack demands the same level of thoroughness. Root out every trace. Then check again.

The Bigger Picture

This incident is not about Red Hat specifically. It is about the npm ecosystem and how deeply trust is baked into the install process. A compromised namespace at a major vendor becomes a distribution channel for malware that reaches thousands of downstream targets in minutes.

It's the preferred attack vector. The Red Hat NPM supply-chain attack shows that namespace takeover, whether through credential theft or CI/CD compromise, is now the preferred attack vector for threat actors who understand developer workflows. Defending against it means treating every npm install as a potential entry point and every pipeline credential as a crown jewel.

Get the affected package list. Scan your environments. Rotate your secrets. Then rethink how much trust you place in any namespace, even one with a Red Hat badge.