This is not a typical "bad package uploaded by a random account" incident. These were packages published under an official-looking Red Hat Cloud Services npm scope. That makes the attack more dangerous because developers and build systems are more likely to trust them.
What Happened
According to Aikido, compromised versions of @redhat-cloud-services npm packages were published with a malicious preinstall script. That detail matters. In npm, a preinstall script can run automatically when a package is installed, before the application imports or uses the package. In other words, simply running npm install may be enough to execute the malware.
The malware reportedly searched for secrets and credentials on the system, including cloud credentials, GitHub tokens, npm tokens, Kubernetes configuration, SSH keys, Docker credentials, .env files, and CI/CD secrets. The goal was not just to infect one project, but to harvest credentials that could let attackers move into other repositories, package registries, or cloud environments.
Security firms have connected this to the broader Mini Shai-Hulud activity seen across the npm ecosystem in recent months. Earlier waves affected packages related to SAP, TanStack, AntV, and other developer ecosystems. Microsoft, Snyk, StepSecurity, Endor Labs, and others have published research on similar Mini Shai-Hulud-style attacks targeting CI/CD workflows, npm publishing, and developer secrets.
How Bad Is It
For anyone who installed the affected versions, this should be treated as a high-severity incident. For organizations that installed them in CI/CD, build servers, release pipelines, or developer machines with access to production secrets, it should be treated as critical.
The reason is simple: credential theft changes the blast radius. A malicious package does not need to compromise your production application directly. If it steals a GitHub token, npm token, AWS key, Azure credential, GCP service account, Kubernetes config, or Vault token, the attacker may be able to compromise other systems that never used the package at all.
The download count is not huge compared with packages like React, Lodash, or Axios, but that does not make the incident harmless. Aikido estimated roughly 117,000 weekly downloads across the affected Red Hat Cloud Services packages. That is modest by npm mega-package standards, but the likely users are developers, internal tools, cloud dashboards, and CI systems — environments that often hold exactly the secrets attackers want.
Why Supply-Chain Attacks Like This Are So Dangerous
Modern software depends on thousands of third-party packages. Most teams do not manually inspect every dependency update, and build systems often install packages automatically from lockfiles or registries.
That creates a dangerous trust chain:
- A developer trusts a package
- The project trusts the developer's lockfile
- CI trusts the project
- Cloud deployments trust CI
- Package registries trust publish credentials
- Attackers only need to break one link
Mini Shai-Hulud-style malware is especially concerning because it appears designed to spread by stealing credentials that can be used to publish more malicious packages or access more repositories. StepSecurity previously described Mini Shai-Hulud as a self-spreading supply-chain attack that compromises legitimate npm packages by targeting CI/CD pipelines and developer secrets.
What Makes This Incident Different
A few details stand out.
First, the packages were under the @redhat-cloud-services npm scope, which gives them an appearance of legitimacy. Developers are more likely to trust scoped packages associated with a known vendor.
Second, the malware used install-time execution. A package with a malicious preinstall script can run during dependency installation. That means the attack can trigger in local development, automated tests, Docker builds, GitHub Actions, Jenkins, or any build system that installs npm dependencies.
Third, this fits into a larger pattern. The Red Hat Cloud Services compromise appears to be part of a broader wave of attacks against developer ecosystems. Similar Mini Shai-Hulud campaigns have been reported against SAP-related packages, TanStack packages, AntV packages, and other npm packages.
Who Should Worry
You should investigate immediately if any of these are true:
| Condition | Why It Matters |
|---|---|
You use packages under @redhat-cloud-services | Direct exposure to the compromised scope |
You ran npm install, npm ci, yarn install, or pnpm install after June 1 | Install scripts may have executed |
| You installed dependencies in CI/CD (GitHub Actions, GitLab CI, CircleCI, Jenkins, etc.) | Build environments often hold valuable secrets |
| Your build environment had access to cloud credentials, tokens, or SSH keys | Primary targets of the credential harvester |
| You maintain npm packages with automated CI/CD publishing | Compromised tokens can be used to publish malicious versions |
How to Check Your Projects
Start by searching your dependency files:
bashgrep -R "@redhat-cloud-services" package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/nullFor a monorepo, search recursively:
bashfind . -name "package.json" -o -name "package-lock.json" -o -name "yarn.lock" -o -name "pnpm-lock.yaml" \
| xargs grep "@redhat-cloud-services"If you find a match, compare the package and version against the affected list from the security advisories. Aikido's report lists affected packages and versions, and other researchers are tracking the campaign as it develops.
What to Do If You Installed an Affected Version
Do not assume that deleting node_modules fixes the problem. If the malware executed, the main concern is already stolen credentials.
Identify where the package was installed. Check developer laptops, CI logs, Docker builds, preview environments, and release systems.
Rotate exposed secrets. Prioritize GitHub tokens, npm tokens, cloud keys, Kubernetes credentials, Vault tokens, SSH keys, Docker registry credentials, and CI/CD secrets.
Audit recent activity. Look for unexpected npm publishes, new GitHub Actions workflows, suspicious commits, new deploy keys, unknown cloud users, unusual API calls, or new service account activity.
Rebuild from clean environments. Avoid reusing potentially compromised build runners or cached dependency directories until they have been reviewed or replaced.
Pin and verify dependencies. Use lockfiles, avoid floating versions, and make sure your package manager is resolving to safe versions.
Disable install scripts where possible. In some workflows, npm ci --ignore-scripts can reduce risk, though it may break packages that legitimately need install scripts.
Review package publishing permissions. Use least-privilege tokens, short-lived credentials, trusted publishing where appropriate, and protected CI workflows.
Lessons for Developers and Security Teams
This incident is a reminder that dependency security is not only about vulnerable code. It is also about build-time behavior, registry trust, identity, and credential hygiene.
A package can be safe one day and malicious the next. A trusted maintainer account, CI workflow, or publishing token can become the attacker's path into the ecosystem. And once malware runs inside CI, it may see secrets that are far more valuable than anything inside the package itself.
| Defense Layer | What It Protects Against |
|---|---|
| Lockfiles and dependency review | Unauthorized version changes |
| Restricted CI secrets | Limits blast radius if install scripts execute |
| Short-lived credentials | Stolen tokens expire before they can be abused |
| Install script monitoring | Catches malicious preinstall/postinstall behavior |
| Segmented publishing permissions | Prevents compromised CI from publishing malicious packages |
| CI/CD treated as production infrastructure | Higher scrutiny on automation that handles secrets |
Bottom Line
This Red Hat npm package compromise is real, serious, and part of a wider wave of supply-chain attacks against developer ecosystems. It is not likely to affect every JavaScript project, but for teams that installed the affected packages — especially in CI/CD — the risk is significant.
The right mental model is not "we installed a bad package, remove it." The right model is "malware may have run in an environment with sensitive credentials." That means investigation, secret rotation, and CI/CD hardening should happen quickly.
Sources: - Aikido — Red Hat npm Packages Compromised: Credential-Stealing Worm