Miasma Worm Republishes 96 Versions of 32 Red Hat npm Packages to Steal Cloud Credentials

The supply chain attacks worth fearing are the ones where the legitimate publisher is still the legitimate publisher on paper, and that is exactly what happened to the official @redhat-cloud-services npm namespace on June 1, 2026. Between roughly 10:54 and 14:23 UTC, in three rapid waves, an attacker republished 96 malicious versions across 32 packages in that namespace and let npm itself do the distribution, because every tarball was signed and uploaded through normal Red Hat release plumbing rather than smuggled in from a typosquat. The compromise was reverse engineered and named by Wiz Research, which called the payload Miasma: The Spreading Blight, and was confirmed in parallel by Snyk, JFrog, and Sonatype, with broader reporting from BleepingComputer and The Hacker News.

The initial access was a compromised Red Hat employee GitHub account, and the campaign turned efficient when the attacker abused GitHub Actions OIDC tokens issued from three internal RedHatInsights repositories, frontend-components, javascript-clients, and platform-frontend-ai-toolkit, all of which already held publish authority over the @redhat-cloud-services namespace. The attacker pulled the legitimate tarballs, injected a preinstall hook into each package, and republished the tampered builds under fresh version numbers using the trust those repositories had with npm, which preserved the provenance metadata downstream consumers were trained to treat as a green light. Aggregate weekly downloads across the affected packages sat near 117,000 according to the Wiz and Snyk advisories, and although npm and Red Hat revoked most malicious versions within hours, any CI runner or developer workstation that fired npm install during the window had already executed the payload.

The payload, a variant of the Mini Shai-Hulud npm worm that Wiz tracks as Miasma, has two jobs, sweeping credentials and then propagating. On install, the preinstall hook hunted AWS, GCP, and Azure identities, SSH private keys, npm and PyPI publish tokens, GitHub Actions secrets including GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN, Kubernetes kubeconfig files and service account tokens, HashiCorp Vault tokens, Docker registry credentials, and any .env file it could reach, as documented by SafeDep and JFrog. The self-replicating half then used stolen npm tokens to enumerate other packages the victim could publish and tried to inject itself into them, which is how a compromise at one company becomes a compromise across a supply graph nobody mapped in advance.

The detection and response gap

Miasma was built to slip past assumptions defenders rely on, and each one maps to a control that did not fire when it needed to:

• Provenance metadata looked correct. Because the tarballs were republished from the legitimate RedHatInsights repositories through GitHub Actions OIDC, npm recorded each publication as coming from the expected source, so tooling that trusts provenance signatures had no reason to flag the new versions.
• Preinstall hooks ran with full developer privilege. npm preinstall executes shell before any sandbox or container that security tooling relies on, so the credential sweep ran as the user who invoked npm install with access to every secret that user had on the machine or runner.
• OIDC trust outranked human review. Federated tokens from a trusted repository feel like an upgrade over long-lived API keys, but once an attacker reaches the repository and triggers workflows, that token chain becomes the publish path with no human in the loop.
• The window was hours, not days. Three waves between 10:54 and 14:23 UTC means any organization that ran npm install once that morning had lost credentials before the first advisory appeared, and any nightly scan was not going to catch it in time.

Mapping the behavior to MITRE ATT&CK

Translating the Miasma kill chain into ATT&CK gives a blue team something concrete to build detections against and then validate:

• T1195.002 Compromise Software Supply Chain: republishing 96 versions of 32 official packages so consumers pulled the malicious build through normal dependency resolution.
• T1078 Valid Accounts and T1528 Steal Application Access Token: a compromised Red Hat employee account plus GitHub Actions OIDC tokens to publish under legitimate identity.
• T1546 Event Triggered Execution: the npm preinstall hook as the execution trigger so the payload runs as a side effect of routine dependency installation.
• T1552.001 Credentials In Files and T1555 Credentials from Password Stores: harvesting kubeconfig files, .env files, Vault tokens, Docker credentials, and SSH keys from the install environment.
• T1071.001 Web Protocols and T1080 Taint Shared Content: exfiltrating secrets over HTTPS, then using stolen npm tokens to inject the worm into additional packages the victim can publish.

Operationalizing a response

If any pipeline or workstation in your environment ran npm install on June 1, 2026, treat that machine as compromised until the cleanup below has been completed and verified, because the speed at which a credential sweep turns into lateral movement does not give you a wait and see posture:

1. Diff every package-lock.json and pnpm-lock.yaml against the version lists published by Wiz, Snyk, JFrog, and Sonatype, and flag any environment that resolved a @redhat-cloud-services package between 10:54 and 14:23 UTC on June 1, 2026, even briefly.
2. Rotate every secret reachable from those environments, including AWS, GCP, and Azure credentials, SSH private keys, npm and PyPI publish tokens, GitHub Actions secrets (GITHUB_TOKEN and ACTIONS_RUNTIME_TOKEN), Kubernetes service account tokens and kubeconfigs, HashiCorp Vault tokens, Docker registry credentials, and any .env values present.
3. Audit your own npm publish history for unauthorized version bumps, because if a developer with publish rights ran the worm, their tokens may already have seeded the next wave on packages your organization owns.
4. Pin @redhat-cloud-services dependencies to known good versions identified after the revocation, refresh lockfiles, and rerun npm install against a clean mirror so any cached tarballs are replaced.
5. Constrain GitHub Actions OIDC trust policies so federated tokens cannot publish to npm without a gating step, and tighten the scope of each repository with publish authority over a shared namespace.

How BlueTeamAutomation closes the loop

Doing all of the above by hand, after the malicious versions are already in your lockfiles, is the slow path an attacker is counting on. BlueTeamAutomation runs the full blue-team workflow against this class of npm supply-chain worm continuously and on hardware you control:

• BAS validation. BASzy emulates the Miasma behavior end to end, a tampered preinstall hook sweeping cloud credentials and beaconing them over HTTPS, so you learn which controls actually fire while it is still a drill instead of a postmortem.
• EDR. On-device detection catches an npm child process spawning a shell that touches kubeconfig, .env, SSH, and cloud credential files in quick succession, the local signal that fires even when the outbound connection looks like ordinary developer traffic.
• SIEM correlation. npm install events, endpoint and runner process telemetry, GitHub Actions audit logs, and cloud control plane reads collapse into one timeline, so a freshly published @redhat-cloud-services version plus a credential read plus an unexpected egress becomes one alert rather than three signals nobody stitches together.
• SOAR response. Automated playbooks isolate the affected workstation or runner, revoke and rotate exposed cloud and CI tokens, force a lockfile refresh, and open the incident inside the minutes that decide how far the worm reaches.
• Compliance evidence. Every validation run, detection, and response action is captured as audit-ready evidence for SOC 2, ISO 27001, and the incident reporting obligations your customers and regulators expect.

The lesson behind Miasma is the same one Megalodon and Nx Console already taught about GitHub Actions: the boundary between your build pipeline and your production crown jewels is now a single OIDC token chain away from collapse, and continuous validation paired with local detection and automated response is what stands between catching the next supply-chain campaign in a drill and explaining to your customers why their secrets walked out of your CI logs.