On June 1, 2026, attackers compromised 32 official npm packages under @redhat-cloud-services. They pushed backdoored versions that run credential-stealing code the moment a developer runs npm install. This is not a typosquatting campaign with fake package names. It is a real npm supply chain attack against a legitimate, trusted namespace that developers use and pull automatically. The attack hit 96 versions across 32 packages with over 116,000 weekly downloads combined. If your project uses any @redhat-cloud-services package and you ran npm install after June 1, treat every secret on that machine as compromised.
How the Attack Worked
A Red Hat employee’s GitHub account was compromised before the attack. Dark web firm Whiteintel found a Red Hat GitHub credential and session cookie in infostealer logs from April 13 and May 15, 2026. The attackers used those credentials to access three RedHatInsights repositories: frontend-components, javascript-clients, and platform-frontend-ai-toolkit.
They injected malicious GitHub Actions workflows into those repositories. Because the packages use GitHub Actions OIDC tokens for publishing, the compromised workflows pushed backdoored versions to npm with valid provenance attestations. To a developer, the packages looked completely legitimate. According to the Wiz Research analysis, the packages came with valid SLSA provenance, meaning supply chain verification tooling did not flag them as suspicious.
The malicious payload sat in a heavily obfuscated index.js file. The attacker used eval() and ROT-based string decoding to hide the logic. The key mechanic was the preinstall script in package.json:
{
"scripts": {
"preinstall": "node index.js"
}
}npm runs preinstall scripts automatically during npm install, before any application code executes. Simply resolving the dependency triggered the payload. No user interaction needed.
What the Miasma Worm Steals
The malware targeted every high-value credential on the infected machine:
- GitHub access tokens and session cookies
- npm publish tokens
- AWS, GCP, and Azure cloud credentials and IAM configurations
- SSH private keys from
~/.ssh/ - Environment variables and
.envfiles - Crypto wallet keys and seed phrases
- CI/CD pipeline secrets
The GCP and Azure identity collectors are new in this variant. Earlier Shai-Hulud versions focused on static secret extraction. This version also enumerates what cloud identities the compromised machine can access, going after IAM roles and service account permissions.
All stolen data is encrypted and sent to attacker-controlled GitHub repositories. The malware then tries to spread itself. Once it has the victim’s npm token, it publishes backdoored versions of other packages the compromised account can access. That is how supply chain worms propagate horizontally across the ecosystem.
Which Packages Are Affected
The compromised packages sit under the @redhat-cloud-services npm scope. Key packages include frontend-components, javascript-clients, and packages from the platform-frontend-ai-toolkit family. Check your project now:
# Check if your project pulls any @redhat-cloud-services packages
grep -r "redhat-cloud-services" package.json package-lock.json yarn.lock
# List all installed packages in scope
npm list | grep redhat-cloud-services
# Check exact versions installed
npm list --depth=0 | grep redhat-cloud-servicesAccording to Aikido Security’s full analysis, most malicious versions were revoked by npm within hours of disclosure on June 1. But any package installed during the compromised window (roughly June 1, 06:00 to 15:00 UTC) should be treated as tainted.
Check your lockfile timestamps and CI build logs:
# Check package versions in lockfile
cat package-lock.json | grep -A3 "redhat-cloud-services"
# Review CI build logs for npm install runs on June 1
# Look for runs between 06:00 UTC and 15:00 UTC on June 1, 2026Rotate Credentials on Affected Machines
Take these steps on every machine that may have run a compromised install:
# Revoke and regenerate npm tokens
npm token list
npm token revoke TOKEN_ID
npm token create
# Rotate AWS credentials
aws iam delete-access-key --access-key-id OLD_KEY_ID --user-name USERNAME
aws iam create-access-key --user-name USERNAME
# Rotate GCP service account keys
gcloud iam service-accounts keys delete KEY_ID --iam-account SA_EMAIL
gcloud iam service-accounts keys create new-key.json --iam-account SA_EMAIL
# Rotate Azure service principal credentials
az ad sp credential reset --name YOUR_SP_NAMEThe malware specifically targets SSH private keys. If any developer who may have run a compromised install has SSH access to production Linux servers, rotate those keys immediately. Our guide on SSH key sprawl on Linux covers how to audit and replace keys across your server fleet quickly.
Audit Your GitHub Actions Workflows
The attack vector was GitHub Actions OIDC. Review your own workflows for unexpected changes:
# Review recent changes to workflow files
git log --oneline .github/workflows/
# Check for unexpected modifications in the last 30 days
git diff HEAD~30 .github/workflows/
# Review OIDC permissions in your workflows
grep -r "id-token" .github/workflows/
grep -r "packages: write" .github/workflows/If any workflow was modified by an account you do not recognise, treat every secret that workflow had access to as compromised and revoke immediately.
The Broader Pattern in 2026
This npm supply chain attack is not isolated. TeamPCP published the full Shai-Hulud source code to GitHub on May 12, 2026, alongside posts on BreachForums encouraging copycat campaigns. That is why attribution is now difficult. Any threat actor can adapt the tooling.
Previous campaigns in this wave hit Aqua Trivy, Checkmarx KICS, Bitwarden, SAP, TanStack, and the GitHub Nx Console. A separate campaign called Megalodon compromised GitHub Actions workflows to harvest CI/CD secrets across dozens of projects. The common thread is GitHub Actions OIDC token abuse. Workflows with permission to publish packages become attack vectors when the account owning the workflow is compromised.
For Linux servers and self-hosted CI/CD systems, the credential theft has direct consequences. The malware targets SSH keys, cloud configuration files under ~/.aws, ~/.config/gcloud, and ~/.azure, and environment variables containing database passwords and API tokens. Any developer who ran a compromised npm install on a machine with SSH access to production Linux infrastructure is a potential pivot point into that infrastructure. Server-side hardening limits the blast radius. Restricting trusted SSH keys, using short-lived certificates, and applying least privilege to CI/CD service accounts all reduce what an attacker can do after stealing credentials. Our Linux server hardening checklist covers those controls.
Summary
If your team uses any @redhat-cloud-services npm package and ran npm install on or after June 1, 2026, act now. Rotate npm tokens, GitHub tokens, cloud credentials, and SSH keys on every affected machine. Audit GitHub Actions workflows for unexpected changes. Review server authorized_keys files and remove keys from potentially compromised developer machines. This npm supply chain attack shows that even packages from trusted publishers can be compromised through account hijacking and CI/CD pipeline abuse. Install-time execution means there is no safe way to inspect a package before malicious code runs. Fast credential rotation after exposure is the only reliable response.