Red Hat NPM Packages Backdoored in Supply-Chain Attack

It began Monday. Security researchers at Aikido confirmed this week that Red Hat NPM packages backdoored through the company's official @redhat-cloud-services channel, and they've been pushing a malicious worm that steals credentials and spreads from machine to machine. But it remained active at the time the initial report went live.

The threat actor took control of a namespace widely trusted by developers who rely on Red Hat cloud services. And that trust is precisely what made this attack so dangerous. Developers pulling packages from an official channel do not expect to get burned. That assumption collapsed on Monday.

The Infection Chain

More than 30 packages appear to have been affected. The compromised packages execute an obfuscated payload during the npm install process. The payload runs before a developer imports or actually uses the package in a production environment. Simply installing it is enough to get infected. You do not need to run anything. You do not need to deploy anything. The damage is already done.

It's a vicious cycle. But it remains unclear precisely how the threat actor took control of the @redhat-cloud-services namespace, and researchers point to one likely explanation: compromised credentials, possibly obtained through a previous supply-chain attack. One breach feeds the next, and the next breach feeds another.

What the Malware Steals

Security firm Socket analyzed the malware and found it was designed to collect a broad range of sensitive credentials. The shopping list is alarming.

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

Once a system is infected, the malware encrypts the stolen credentials and sends them through a web request. But there is a catch. If that transmission fails, a fallback mechanism kicks in. The malware publishes the encrypted data directly into a compromised GitHub repository, assuming it holds the credentials for that repository too.

The Worm Spreads Further

The worm, dubbed Shai-Hulud, then republishes backdoored packages to third-party accounts that the infected device has access to. It moves laterally. It propagates. It finds new hosts. The worm has all the hallmarks of malware released last month as freely available open source. TeamPCP was the first group to use Shai-Hulud, and the group promoted a competition that promised a $1,000 payment to the hacker who carried out the biggest supply-chain attack using the malware. Now the worm is in the hands of many other threat groups. Supply-chain attacks may ramp up further.

So the malware devotes considerable attention to CI/CD systems, which automate the building, testing, and deploying of code changes, and Monday's attack spread through GitHub Actions OIDC; it's a security measure that uses temporary credentials for cloud services, indicating that Red Hat's own CI/CD pipeline was compromised, but the breach of that pipeline was very possibly the result of a previous supply-chain attack. It infected an employee's machine.

Red Hat Responds

In an email sent after the initial report went live, Red Hat said it removed the malicious packages.

"The packages are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system," the company stated. "While our investigation is ongoing, we have not identified any impact to customer or partner environments or Red Hat production systems."

But that framing misses something. The Red Hat NPM packages backdoored in this attack executed their payload at install time. Any developer or CI pipeline that pulled those packages during the window of exposure ran the malicious code. The fact that the packages were intended for internal development does not erase that risk. Researchers at Socket put it bluntly.

"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."

Why This Keeps Happening

Most, but not all, of the packages had been taken down in the hours following the incident. But remediation is not always straightforward. The source article points to a recent supply-chain attack on Checkmarx as a cautionary tale. The security firm was breached using credentials stolen from a supply-chain attack on the Trivy software developer. Checkmarx failed to fully drive out the responsible party and was hit two more times afterward. The pivot to Checkmarx and the failure to fully remediate the initial breach demonstrates how difficult complete recovery really is.

Checkmarx Shows the Danger

The cycle does not end when the malicious packages come down. Credentials harvested in this attack could fuel the next one, and the next one could strike an organization that has no idea it is connected to the original breach. The Red Hat NPM packages backdoored on Monday may be the start of a longer chain.

Immediate Steps

Given the success of other recent supply-chain attacks, anyone who touched one of the affected packages in the past 36 hours should assume compromise of their workstations, CI/CD pipelines, and all credentials for cloud services and repositories. That means employees should drop what they are doing and investigate thoroughly.

• Check all systems that pulled from @redhat-cloud-services during the exposure window
• Audit CI/CD pipelines for signs of republished packages
• Use the indicators of compromise published by both Socket and Aikido

Both security firms have published lists of affected packages and indicators of compromise, and any organization that might've been exposed should make use of those resources promptly. The Red Hat NPM packages backdoored in this incident are no longer live. Credentials are still out there.