Red Hat Cloud Services npm Packages Compromised in Miasma Supply Chain Attack

Multiple npm packages under the trusted @redhat-cloud-services namespace were compromised in a supply chain attack that added credential-stealing malware to official package releases. The campaign, called Miasma, affected frontend components, API clients, MCP packages, and developer tooling used around Red Hat Cloud Services projects.

The Red Hat security bulletin says the compromise was publicly disclosed on June 1, 2026. Red Hat’s initial investigation found that a compromised GitHub account was used to inject malicious code into packages maintained in a Red Hat GitHub organization.

Aikido reported that 96 versions across 32 packages were compromised and that the packages averaged 116,991 weekly downloads in total. The malware resembles Mini Shai-Hulud, a credential-stealing worm family whose tooling was recently made public.

What Happened in the Red Hat npm Compromise

This was not a typosquatting campaign. Attackers abused a legitimate namespace that developers already trusted. That makes the incident more dangerous than a fake package using a lookalike name, because normal dependency updates could pull the malicious versions into developer machines or CI/CD runners.

Wiz Research said the affected packages contained unauthorized modifications that did not match their corresponding source repositories. The packages included installation-time execution mechanisms, including preinstall scripts that ran a malicious index.js file during package installation.

JFrog Security Research analyzed the Miasma payload and said the campaign used the GitHub repository description “Miasma: The Spreading Blight” as a marker. JFrog also said the package versions ran before application code imported anything from them.

Key Details at a Glance

Item	Details
Campaign name	Miasma
Affected namespace	@redhat-cloud-services
Reported scope	32 packages and 96 compromised versions
Main malware behavior	Credential theft, cloud identity collection, GitHub dead-drop exfiltration, persistence, and possible propagation
Attack entry point	Compromised GitHub account and unauthorized commits to Red Hat repositories
Customer impact status	Red Hat says current findings show no customer action is required

The malicious packages used npm install-time behavior to execute code automatically. The npm lifecycle scripts documentation explains that package scripts can run at preset lifecycle events, including preinstall, install, and postinstall stages.

In this case, the dangerous point was simple: the payload could run as soon as a developer or CI pipeline installed the package. That means projects did not need to import the package in application code for the malware to execute.

Why GitHub Actions OIDC Matters in This Attack

The attack also shows how CI/CD publishing workflows can become a supply chain risk. Aikido said the affected packages were published through GitHub Actions OIDC, which suggests the pipeline itself was compromised rather than a long-lived npm token alone.

GitHub Actions OIDC allows workflows to use short-lived identity tokens instead of storing long-lived cloud credentials as secrets. That improves security when configured correctly, but it also means attackers who control a trusted workflow can abuse the trusted publishing path.

Red Hat said preliminary analysis points to unauthorized commits in the RedHatInsights GitHub organization. Those commits were used to introduce malicious code into repositories tied to affected packages.

What the Malware Tried to Steal

• GitHub tokens, including tokens exposed in developer and CI environments.
• npm publish tokens and other package registry credentials.
• AWS, Google Cloud, and Azure credentials or identity material.
• Kubernetes service account tokens and kubeconfig files.
• HashiCorp Vault tokens and other infrastructure secrets.
• SSH private keys, Docker registry credentials, GPG keys, and .env files.
• Secrets available to GitHub Actions runners or developer workstations.

Aikido’s analysis warned teams that any environment installing affected package versions since June 1 should treat CI secrets, cloud credentials, SSH keys, and npm tokens as compromised. That guidance applies most strongly to developer systems and CI runners where package installation occurred.

The malware family has also moved beyond simple static file theft. Wiz said Miasma added collectors for GCP and Azure identities, which suggests attackers want not only secrets but also the cloud identities available from infected machines.

Affected Package Versions

#	Package	Reported compromised versions
1	@redhat-cloud-services/chrome	2.3.1, 2.3.2, 2.3.4
2	@redhat-cloud-services/compliance-client	4.0.3, 4.0.4, 4.0.6
3	@redhat-cloud-services/config-manager-client	5.0.4, 5.0.5, 5.0.7
4	@redhat-cloud-services/entitlements-client	4.0.11, 4.0.12, 4.0.14
5	@redhat-cloud-services/eslint-config-redhat-cloud-services	3.2.1, 3.2.2, 3.2.4
6	@redhat-cloud-services/frontend-components	7.7.2, 7.7.3, 7.7.5
7	@redhat-cloud-services/frontend-components-advisor-components	3.8.2, 3.8.4, 3.8.6
8	@redhat-cloud-services/frontend-components-config	6.11.3, 6.11.4, 6.11.6
9	@redhat-cloud-services/frontend-components-config-utilities	4.11.2, 4.11.3, 4.11.5
10	@redhat-cloud-services/frontend-components-notifications	6.9.2, 6.9.3, 6.9.5
11	@redhat-cloud-services/frontend-components-remediations	4.9.2, 4.9.3, 4.9.5
12	@redhat-cloud-services/frontend-components-testing	1.2.1, 1.2.2, 1.2.4
13	@redhat-cloud-services/frontend-components-translations	4.4.1, 4.4.2, 4.4.4
14	@redhat-cloud-services/frontend-components-utilities	7.4.1, 7.4.2, 7.4.4
15	@redhat-cloud-services/hcc-feo-mcp	0.3.1, 0.3.2, 0.3.4
16	@redhat-cloud-services/hcc-kessel-mcp	0.3.1, 0.3.2, 0.3.4
17	@redhat-cloud-services/hcc-pf-mcp	0.6.1, 0.6.2, 0.6.4
18	@redhat-cloud-services/host-inventory-client	5.0.3, 5.0.4, 5.0.6
19	@redhat-cloud-services/insights-client	4.0.4, 4.0.5, 4.0.7
20	@redhat-cloud-services/integrations-client	6.0.4, 6.0.5, 6.0.7
21	@redhat-cloud-services/javascript-clients-shared	2.0.8, 2.0.9, 2.0.11
22	@redhat-cloud-services/notifications-client	6.1.4, 6.1.5, 6.1.7
23	@redhat-cloud-services/patch-client	4.0.4, 4.0.5, 4.0.7
24	@redhat-cloud-services/quickstarts-client	4.0.11, 4.0.12, 4.0.14
25	@redhat-cloud-services/rbac-client	9.0.3, 9.0.4, 9.0.6
26	@redhat-cloud-services/remediations-client	4.0.4, 4.0.5, 4.0.7
27	@redhat-cloud-services/rule-components	4.7.2, 4.7.3, 4.7.5
28	@redhat-cloud-services/sources-client	3.0.10, 3.0.11, 3.0.13
29	@redhat-cloud-services/topological-inventory-client	3.0.10, 3.0.11, 3.0.13
30	@redhat-cloud-services/tsc-transform-imports	1.2.2, 1.2.4, 1.2.6
31	@redhat-cloud-services/types	3.6.1, 3.6.2, 3.6.4
32	@redhat-cloud-services/vulnerabilities-client	2.1.8, 2.1.9, 2.1.11

Wiz also noted a later update on June 4 involving another wave linked to the same campaign family. That wave used binding.gyp to execute code during package installation, showing that the operators or copycats are testing quieter execution paths.

JFrog described this binding.gyp method as an evasive install-time execution path. Instead of relying only on a visible preinstall script in package.json, attackers can abuse node-gyp behavior to run code during package configuration.

Red Hat Says Hybrid Cloud Console Builds Were Protected

The Red Hat bulletin says the affected packages are frontend JavaScript libraries used in the Hybrid Cloud Console web interface. Red Hat also said no release of the Hybrid Cloud Console was published during the compromise window.

Red Hat added that its publication process includes protections that strip installation-time scripts from packages before deployment to console.redhat.com. Based on current findings, Red Hat says no customer actions are required, though its investigation remains ongoing.

That does not remove the risk for developers, CI environments, downstream projects, or organizations that installed the compromised npm versions directly. Those environments should still treat affected installations as potential credential exposure events.

Why Preinstall Malware Is Hard to Contain

Preinstall malware is dangerous because the attack begins during dependency installation. Developers may run npm install during routine development, while CI runners may execute the same command automatically during build or test jobs.

The npm documentation makes clear that lifecycle hooks are part of normal package behavior. That normality gives attackers cover, because many legitimate packages also run install scripts for setup, compilation, or native module preparation.

Temporary safeguards such as npm ci –ignore-scripts can reduce exposure in CI pipelines, but teams should test this carefully. Some legitimate packages need install scripts, so organizations may need an allowlist approach rather than a blanket rule in every environment.

What Developers and Security Teams Should Do Now

• Search package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, yarn.lock, and CI logs for affected @redhat-cloud-services versions.
• Remove compromised package versions and regenerate lockfiles from trusted metadata.
• Use npm ci –ignore-scripts in CI while investigating, where builds can tolerate it.
• Inspect developer machines and CI runners that installed affected packages on or after June 1, 2026.
• Look for unexpected GitHub repositories with the description “Miasma: The Spreading Blight.”
• Check for persistence files and AI tool hooks before revoking exposed tokens.
• Rotate GitHub, npm, cloud, Kubernetes, Vault, SSH, Docker, and CI/CD credentials after persistence is removed.
• Rebuild affected CI runners and high-risk developer workstations from clean images.

Teams using trusted publishing should also review their workflow permissions. The GitHub OIDC documentation explains that OIDC removes the need for long-lived secrets, but workflow permissions and trust relationships still need tight controls.

Incident responders should avoid rotating tokens too early if they suspect the destructive token monitor described by researchers is still active. The safer sequence is to isolate affected systems, remove persistence, collect evidence, and then rotate or revoke credentials.

Why This Incident Matters Beyond Red Hat Packages

The Miasma campaign shows how attackers can use trusted build and release systems as delivery channels. Once a legitimate namespace gets abused, downstream users may install malicious code through normal dependency management.

The bigger issue is developer infrastructure. CI runners, package publishers, cloud identities, AI coding tools, Kubernetes clusters, and local workstations all hold credentials that attackers can use to move from one compromise to many others.

For security teams, the priority is not only to remove one package version. The priority is to identify every machine that installed affected versions, understand what secrets were present there, and prevent a stolen credential from enabling the next supply chain incident.

FAQ