Mini Shai-Hulud-Style Worm Compromises 32 Red Hat Cloud Services npm Packages

A trusted package namespace is exactly where defenders least want to find a credential-stealing worm.

On June 1, 2026, security researchers reported that multiple official npm packages under Red Hat’s @redhat-cloud-services scope were compromised in a Mini Shai-Hulud-style supply-chain attack. The campaign, dubbed Miasma, affected 32 packages and 96 malicious package versions, according to Aikido Security, with the compromised packages collectively drawing roughly 116,991 weekly downloads.

The operational concern is not just package tampering. The injected malware was built to execute during installation, hunt for developer and CI/CD secrets, and potentially use stolen credentials to spread further through the software supply chain.

What Happened

The compromised packages were published under the @redhat-cloud-services npm scope, a namespace associated with Red Hat Cloud Services frontend and client-side tooling. Researchers from Aikido, StepSecurity, Wiz, Orca Security, Mend, and others reported that malicious versions appeared on June 1, 2026.

Aikido said the incident involved 96 compromised versions across 32 packages. StepSecurity’s analysis also identified a broad set of affected Red Hat Cloud Services packages, including @redhat-cloud-services/chrome, @redhat-cloud-services/frontend-components, @redhat-cloud-services/rbac-client, @redhat-cloud-services/notifications-client, @redhat-cloud-services/vulnerabilities-client, and multiple other frontend, client, and MCP-related packages.

The malicious packages carried a preinstall hook in package.json, causing the payload to run automatically during npm install. StepSecurity reported that the malicious index.js file was roughly 4.2 MB and buried behind multiple layers of obfuscation. Mend separately reported a similar 4.1 MB obfuscated JavaScript payload.

That detail matters. A preinstall script executes before the consuming application runs and before many teams would expect meaningful risk from a dependency. In practice, simply installing an affected version could expose secrets from a developer workstation or CI runner.

Why This Stands Out

This was not a simple npm token theft case, based on the early technical reporting. Aikido said the malicious packages were published via GitHub Actions OIDC, suggesting the attacker abused or compromised the CI/CD path rather than relying only on a long-lived npm publish token.

That is a sharper problem for defenders. Trusted publishing and OIDC reduce the risk created by static registry tokens, but they do not make a release pipeline safe if an attacker can alter workflow logic, hijack a runner, or abuse a trusted identity at publish time.

Aikido reported that a compromised Red Hat employee GitHub account was used to push malicious orphan commits directly to repositories, bypassing normal review paths. StepSecurity also reported that the affected packages were published via GitHub Actions OIDC from the RedHatInsights/javascript-clients repository, pointing to the CI/CD pipeline as the critical trust boundary.

The malware’s behavior also mirrors the pattern seen in Mini Shai-Hulud waves: steal secrets first, then use them to create new downstream compromises. StepSecurity said the payload targeted GitHub Actions secrets, AWS, GCP, Azure, Kubernetes, HashiCorp Vault, npm tokens, and CircleCI tokens. Mend reported targeting that also included Bitwarden and 1Password data.

The Developer Secrets at Risk

The most serious exposure is not the JavaScript package itself. It is what the package can reach at install time.

On a developer machine, that may include npm tokens, cloud CLI credentials, Kubernetes configuration, SSH keys, password-manager artifacts, and local environment variables. In CI, the blast radius can be worse: GitHub Actions secrets, short-lived OIDC tokens, cloud deployment credentials, registry publishing rights, and access to production-adjacent automation.

StepSecurity said the malware was self-propagating and could use stolen npm tokens with npm’s bypass_2fa parameter to republish backdoored package versions, including in environments where account-level two-factor authentication was enabled. That makes this campaign especially dangerous because the attacker does not need every victim to be a high-value target. One infected maintainer or CI system with publishing rights can become the next distribution point.

Affected Package Pattern

The affected packages sit inside a legitimate vendor namespace, which increases trust and lowers suspicion during dependency updates. Reported malicious versions included packages across Red Hat Cloud Services frontend components, generated clients, configuration utilities, rule components, remediations tooling, inventory clients, integrations clients, and MCP-related packages.

Examples reported by Aikido and StepSecurity include:

@redhat-cloud-services/chrome, @redhat-cloud-services/frontend-components, @redhat-cloud-services/frontend-components-utilities, @redhat-cloud-services/rbac-client, @redhat-cloud-services/notifications-client, @redhat-cloud-services/compliance-client, @redhat-cloud-services/host-inventory-client, @redhat-cloud-services/insights-client, @redhat-cloud-services/remediations-client, @redhat-cloud-services/vulnerabilities-client, @redhat-cloud-services/types, and @redhat-cloud-services/javascript-clients-shared.

Teams that installed affected versions on or after June 1, 2026 should treat the host or pipeline as exposed until proven otherwise. In this incident class, deletion of the dependency is not enough; any secrets accessible during installation may already have been collected.

Why This Matters

The Red Hat npm compromise shows how modern supply-chain attacks are moving away from isolated package poisoning and toward release infrastructure abuse.

Package managers, CI systems, trusted publishing, cloud identity, and developer workstations now form one attack surface. A malicious package no longer needs to compromise an end-user application to be useful. It only needs to run once in the right build environment.

For defenders, the key lesson is uncomfortable but practical: package provenance helps answer who published a package, but it does not automatically prove that the publishing workflow was clean. If an attacker controls the workflow path, the package can still look legitimate while carrying hostile code.

Immediate Defensive Actions

Organizations that consumed the affected @redhat-cloud-services packages should identify every installation point, including local developer machines, ephemeral CI runners, build containers, and cached dependency layers.

Priority actions should include removing affected versions, rebuilding from known-clean lockfiles, rotating npm tokens, GitHub tokens, cloud credentials, Kubernetes credentials, Vault tokens, CircleCI secrets, and any CI/CD variables exposed to jobs that ran npm install. Teams should also review GitHub Actions workflow changes, unexpected orphan commits, unusual package publish events, and outbound connections from build jobs around June 1, 2026.

Detection should not stop at the package boundary. Hunt for suspicious preinstall execution, oversized dependency files such as multi-megabyte index.js payloads, unexpected Bun execution, anomalous registry publishes, and new package versions released outside normal maintainer workflow.

Bigger Picture

Miasma fits a broader 2026 pattern of npm and developer-ecosystem attacks inspired by or derived from Mini Shai-Hulud tooling. Earlier waves reportedly affected SAP packages, TanStack packages, Mistral-related packages, PyTorch Lightning on PyPI, Microsoft Durable Task packages, and hundreds of packages tied to compromised maintainers.

The strategic shift is clear: attackers are targeting the machinery that builds software, not just the software that gets shipped. Developer secrets have become the real payload, and package installation is the delivery mechanism.

NeuraCyb's Assessment

The Red Hat Cloud Services npm compromise is a reminder that “trusted” is not the same as “verified at runtime.” Defenders should treat package installation as code execution, CI workflows as privileged identity systems, and developer machines as supply-chain infrastructure. The teams that move fastest here will not be the ones that merely pin dependencies; they will be the ones that can prove what ran, where it ran, and which secrets were reachable when it did.

References

Aikido Security — Red Hat npm Packages Compromised to Spread a Credential-Stealing Worm

StepSecurity — Multiple redhat-cloud-services npm Packages Compromised

Wiz — Miasma: Supply Chain Attack Targeting RedHat npm Packages

Orca Security — Red Hat npm Supply Chain Attack

Mend — RedHat Cloud Services Packages Drop Multi-Cloud Credential Stealer

Help Net Security — Red Hat npm packages compromised in new Mini Shai-Hulud malware wave

SecurityWeek — Supply Chain Attack Hits 32 Red Hat NPM Packages