Red Hat NPM Supply Chain Attack: Runtime Defense Case Against 32 Poisoned Packages in 72 Seconds

The Attack Rode a Routine npm Install, No Click Required

If your build ran npm install on an affected @redhat-cloud-services package during the compromise window, the worm ran on your CI runner before a line of application code executed. It rode the package’s preinstall hook, a script npm runs automatically before the package is even imported, per SecurityWeek’s account citing ReversingLabs and Socket.

Once running, the payload swept the machine. Environment variables, SSH keys, npm authentication tokens, GitHub tokens, cloud credentials for AWS, Azure and GCP, and Kubernetes secrets, all read from the well-known paths where build tooling keeps them. OX Security traced the exfiltration: the worm uses the stolen GitHub token to create a public repo on the victim’s account, described in the attacker’s own words as “Miasma: The Spreading Blight”, then commits the encrypted secrets there. It pings api.anthropic.com as a decoy command channel to send researchers down the wrong path, while the real theft lands in that GitHub repo.

Two details raise this above a routine token grab. The worm self-replicates: it uses stolen npm tokens to republish backdoored versions of other packages the compromised account controls, so each victim becomes the next carrier. And the payload ships a destructive kill-switch that deletes the host if a stolen token is invalidated, which turns incident response itself into a trigger.

GitHub search showing the worm’s self-created repositories, each named Miasma: The Spreading Blight.
Source: JFrog Security Research.

The Root Cause is Install-time Code Execution on a Trusted Package

The npm ecosystem lets a package run arbitrary code at install through lifecycle hooks like preinstall and postinstall. A developer who trusts the @redhat-cloud-services name gets attacker code the moment the package unpacks, with the full permissions of the build user.

Obfuscated payload from a poisoned @redhat-cloud-services package, decoded and run at install time.
Source: JFrog Security Research.

The delivery was not a guessed password. SecurityWeek reports that the attackers likely compromised the CI/CD pipeline and abused GitHub Actions OIDC to publish the poisoned versions, and probably held valid credentials for the @redhat-cloud-services npm scope. The 72-second publish burst across all 32 packages is the signature of an automated pipeline, not a person.

The attack follows the same playbook that hit four SAP packages weeks earlier, which we broke down in the SAP npm attack analysis. Both trace to the Shai-Hulud worm family. The threat actor TeamPCP open-sourced the Mini Shai-Hulud code, so copycats now assemble these campaigns from a published kit. Expect more, not fewer.

Why Detect-and-Respond Loses this Race

Endpoint and workload detection tools work on a fixed loop: observe the behavior, raise an alert, run a response. Kill the process, quarantine the file, page the SOC. That loop has a built-in delay, and this attack finishes inside it.

The worm reads a credential file, encrypts the contents, and pushes them to a remote repo in seconds. By the time a detector scores the anomaly and starts a response, the npm token is already in the attacker’s repo and the worm is published under the victim’s name. Detection after exfiltration tells you which credentials to rotate. The credentials are already gone.

How Inline Runtime Enforcement Stops it at the Kernel

The only control that beats a seconds-long attack is one that decides before the operation returns. AccuKnox runtime security, built on the open-source KubeArmor engine and enforced through eBPF and Linux Security Modules, evaluates policy inline at the syscall, at the same privilege level as the operating system. There is no userspace agent racing the attacker.

Each row is a hard denial, not a log line. The install hook can fire. The credential read never returns the file contents. The egress never reaches the repo. The decision happens at kernel speed, so no window exists for the worm. The CWPP enforcement layer applies the same model on Kubernetes runners, VMs, and bare-metal build servers.

Runtime enforcement in the AccuKnox console, where an unlisted process is denied at the syscall rather than logged after it runs.

Runtime Enforcement is Not the End State

Runtime enforcement stops the theft on a workload you control and have put under policy. It does not remove the poisoned package from your dependency tree, and it does not help on an unmanaged laptop with no enforcement agent. Pair it with a software bill of materials so you can answer which builds pulled an affected version. AccuKnox generates that through xBOM and SBOM tooling, and an admission controller can block a workload whose BOM carries a flagged component before it ever deploys.

Treat install-time code execution as hostile by default. The package registries will not fix this soon, the attack kit is public, and the next poisoned scope is a matter of when. Set default-deny execution and least-privilege file access on your build environment. That policy holds when the next trusted name turns.

See Runtime Enforcement Stop an Attack in Real Time

The same inline model that would have blocked this worm is shown here stopping a live exploit at the kernel.

FAQ