Follow ZDNET: Add us as a preferred source on Google.
ZDNET’s key takeaways
- Red Hat was the victim of an npm security breach.
- The company has removed the affected packages.
- Check whether you use @redhat-cloud-services npm namespace.
The npm repository namespace –the JavaScript runtime environment Node.js package manager — is infamous for security breaches. Now, Red Hat, which, with IBM, just announced Project Lightwell, an AI-powered initiative to find and fix open-source software vulnerabilities, has an npm problem of its own.
Also: Open-source security is a mess – IBM and Red Hat bet $5 billion and 20,000 engineers can fix it
Dozens of JavaScript packages in the company’s @redhat-cloud-services namespace were backdoored with credential-stealing malware targeting secrets in Red Hat developers’ and continuous integration and continuous deployment (CI/CD) systems. The security research company Aikido reported that the namespace was “compromised with a credential-stealing worm. In total, 96 versions across 32 packages have been compromised, cumulatively downloaded 116,991 times per week.”
According to Red Hat security, someone used a compromised GitHub account to inject malicious code into packages maintained in a Red Hat GitHub organization. The affected packages are front-end libraries compiled and bundled into container images during the Red Hat product build process.
What exactly happened?
It appears the malware was added via npm preinstall hooks: Whenever a developer or build system ran “npm install” for an affected package, the malicious code was automatically executed. According to Microsoft’s threat intelligence team, each compromised package added a preinstall script that ran a bloated, heavily obfuscated index.js loader, which then pulled down and executed a payload designed to vacuum up secrets from npm, GitHub, AWS, SSH, and other environments.
Researchers quickly linked the attack to a broader campaign based on the Mini Shai-Hulud malware, an npm-propagating worm used in earlier supply-chain incidents. In the Red Hat case, multiple reports refer to the payload as a new variant dubbed Miasma, which retains Mini Shai-Hulud’s self-spreading behavior while adding more obfuscation and a multistage loading design.
The worm does more than just steal credentials. Once it’s running on a machine with access to other npm packages, it identifies every package the current user can publish and republishes them with the same malicious preinstall payload. That is, each victim becomes a new attacker. Security firms say this “wormable” behavior is what enabled the Red Hat-associated namespace to be contaminated so quickly. Some estimates suggest that more than 30 packages were backdoored in a matter of minutes.
Also: Red Hat Desktop vs. Fedora Hummingbird: Which AI development Linux path is right for you?
While Red Hat hasn’t yet published a detailed post-mortem, independent analyses point to compromised GitHub infrastructure as the initial access vector. Semgrep and other security research companies report that the malicious Red Hat-scoped packages were pushed using GitHub Actions OpenID Connect (OIDC) tokens associated with the RedHatInsights/javascript-clients repository.
Once in, the attackers injected the preinstall hook into multiple packages and versions, often without any corresponding changes in the public source repositories. This is a classic hallmark of build-pipeline compromise.
The executed code scans for and attempts to exfiltrate the following:
- GitHub Actions secrets and access tokens
- GitHub SSH keys and personal access tokens
- AWS, GCP, and Azure cloud credentials
- Kubernetes configuration and tokens
- HashiCorp Vault tokens and other secret manager data
- npm and CircleCI tokens, plus other CI/CD secrets stored in environment variables or configuration files
Also: Rust will save Linux from AI, says Greg Kroah-Hartman
Security vendors warn that anyone who installed the affected versions on a developer workstation, build agent, or CI runner should assume that all accessible tokens and credentials from that environment may now be in an attacker’s hands.
For developers, guidance from multiple firms is explicit:
- Rotate secrets immediately.
- Audit GitHub and cloud activity for suspicious access.
- Rebuild any potentially contaminated environments from known-good baselines.
Red Hat told me, “We immediately initiated an investigation and removed the packages from the npm registry. The packages are strictly limited to internal development, and the malicious code was never published for customer consumption via the console.redhat.com system. While our investigation is ongoing, we have not identified any impact on customer or partner environments or Red Hat production systems.”
In short, this could have been much worse.
Also: Ubuntu 26.04 is the OS for the AI agentic era, says Canonical’s Mark Shuttleworth
In earlier, more general guidance on npm supply-chain attacks, Red Hat Product Security stated that its products rely heavily on strict version pinning and internal mirrors, and that no previously compromised npm packages had been incorporated into supported Red Hat software.
In the wake of the recent incident, however, security researchers are urging organizations not to assume they are safe simply because they use Red Hat offerings. They argue that any build or developer workflow that touched the backdoored packages should be treated as potentially compromised.
What should you do now?
While Red Hat is assuring everyone that the bad code didn’t make it into the public, I remain wary. If you rely on Red Hat cloud services tooling or have ever pulled @redhat-cloud-services packages into your builds, I’d recommend scanning dependency trees for the affected versions, blocking the known-bad releases, and downgrading or replacing them with trusted builds where necessary.
At the same time, I’d assume that any environment where those packages were installed may have had its secrets exposed, and rotate all relevant credentials, for example, GitHub PATs, SSH keys, cloud provider API keys, and CI tokens.
Also: How digitally sovereign is your organization? This Red Hat tool can tell you in minutes
In the long term, the Red Hat npm incident shows again that the npm repositories aren’t all that trustworthy. With even heavyweight Linux and cloud vendors now demonstrably vulnerable to wormable npm malware, the pressure is mounting on both npm’s stewards and major software suppliers to provide stronger guarantees about the provenance and safety of their packages.
In other words, while Red Hat may have pie on its face from this episode, it also underscores just how important Project Lightwell and similar efforts, such as Chainguard’s efforts to find a way to improve everyone’s open-source security, are.
