A npm supply chain attack named Miasma compromised 32 official packages under Red Hat's @redhat-cloud-services namespace on June 1, 2026, injecting a self-propagating credential-stealing worm that fired automatically the moment a developer ran npm install — no user interaction, no visible warning. Two days later, the same worm family returned with a new technique called Phantom Gyp, compromising 57 more packages across multiple maintainer accounts in under two hours on June 3. Wiz Research published an updated advisory on June 4 covering the new wave. Any developer who installed @redhat-cloud-services packages on June 1 — or any of the newly identified packages on June 3 — should treat every credential in that environment as compromised.
How the Red Hat Breach Happened
The attack did not exploit a code vulnerability. According to Wiz Research, the attacker compromised a single Red Hat employee's GitHub account and used the stolen credentials to push orphan commits directly to three RedHatInsights repositories — frontend-components, javascript-clients, and platform-frontend-ai-toolkit. Orphan commits bypass standard pull-request code review gates by being pushed directly to a branch, meaning no reviewer saw the change before it was live.
Those commits introduced a minimal GitHub Actions workflow that requested an OIDC (OpenID Connect) identity token with id-token: write permissions. The workflow then executed an obfuscated payload that used the live OIDC token to publish backdoored package versions carrying valid SLSA provenance attestations — cryptographic signatures generated through Sigstore that npm's trusted-publishing system accepts as proof a package was built by a legitimate pipeline. The packages had not been tampered with after build; the pipeline that built them had simply also been running attacker code at the time.
The attack arrived in two waves on June 1: the first at 6:53 a.m. ET and a second at 9:44 a.m. ET. Most malicious versions were revoked by approximately 9:00 a.m. ET — though two reportedly remained live during the initial disclosure window.
Why Signed Attestations Did Not Catch It
The Miasma attack exposes a fundamental limit in how developers currently use SLSA provenance. SLSA Build Level 3 attestations are designed to verify that a package was built from a trusted source by a trusted pipeline. What they cannot verify is whether that pipeline was itself clean at the moment it ran.
As the Cloud Security Alliance noted in an analysis of the underlying worm family, SLSA attestations are insufficient against attacks that compromise the build environment from within. The attestation was accurate — those packages genuinely were built by Red Hat's pipeline. The pipeline had simply been injected with attacker code first. Every downstream consumer who relied on provenance verification as a primary supply-chain control received a correctly signed package containing a credential-stealing worm.
The Snyk advisory put it plainly: "Exploitation requires no special configuration on your side. The preinstall hook runs by default."
How Miasma Steals Credentials and Spreads
The payload is embedded in a preinstall lifecycle script — a standard npm hook that executes before any application code, automatically, at install time. The script invokes a heavily obfuscated 4.2 MB index.js file using eval() and ROT-based decoding to conceal its logic from static analysis tools.
Once triggered, Miasma harvests a broad range of credentials, including GitHub tokens and personal access tokens, npm authentication tokens, AWS, GCP, and Azure cloud credentials and identity tokens, HashiCorp Vault tokens, Kubernetes service account tokens, SSH keys, Docker registry credentials, GPG keys, and .env files. A notable evolution over predecessor variants is the addition of dedicated collectors for GCP and Azure cloud identities, moving beyond secret extraction toward actively enumerating all cloud access the infected machine holds.
The malware generates a uniquely encrypted payload for each infection, making hash-based detection effective only against specific package versions and significantly complicating broad signature-based detection.
After credential harvesting, Miasma attempts to self-propagate by using stolen npm tokens to republish backdoored versions of other packages the compromised developer account has publish access to — spreading the infection laterally across the npm ecosystem without any further action from the attacker. On developer workstations, Microsoft's analysis found the malware also targeted SSH keys, browser data, and wallet data. In CI/CD environments, it scraped GitHub Actions runner memory for secrets and escalated privileges using passwordless sudo.
A Seven-Week Warning Window Nobody Acted On
Among the most significant dimensions of the incident is the timeline. Dark web monitoring firm Whiteintel reported detecting the compromised Red Hat employee's GitHub credentials and active session cookie in infostealer logs on both April 13 and May 15, 2026 — 49 days before the attack materialized.
That session cookie would have bypassed multi-factor authentication entirely. The credentials and cookie had been packaged, listed, and available on underground markets for seven weeks before anyone weaponized them. As CybelAngel's analysis of the incident noted, the attack illustrates a growing pattern in supply chain intrusions: credentials are exfiltrated by infostealers weeks or months in advance, then activated at the attacker's chosen moment. Continuous dark-web credential monitoring, had it been in place and acted on, could have surfaced the exposure in time to rotate credentials before June 1.
Red Hat's Official Response
Red Hat confirmed the breach in security bulletin RHSB-2026-006 on June 2, acknowledging that unauthorized commits were pushed to repositories within the RedHatInsights GitHub organization using a compromised developer account.
Critically, Red Hat stated that no release of the Hybrid Cloud Console was published during the compromise window, and that its publication process includes protections that strip installation-time scripts from packages before deployment to console.redhat.com. No official Red Hat products were shipped with the backdoored versions.
However, third-party developers who pulled @redhat-cloud-services packages directly into their own CI/CD pipelines or developer workstations during the June 1 window remain at risk. Red Hat has confirmed the investigation is ongoing and that the bulletin will be updated as new information emerges. Microsoft shared its findings with the npm team, which added additional protections on the @redhat-cloud-services namespace to prevent further unauthorized publishing.
What the Miasma Worm Actually Is
Miasma is not a wholly original creation. Wiz's analysis identified it as a variant of Mini Shai-Hulud, a supply chain malware developed and open-sourced by threat actor group TeamPCP — also tracked by Google Threat Intelligence as UNC6780 and by other researchers as DeadCatx3 and PCPcat — in May 2026. TeamPCP published the full source code to GitHub and advertised it on BreachForums, lowering the barrier to entry for any actor willing to adapt the framework.
The cosmetic changes in Miasma are largely thematic: references to the Dune universe have been replaced by Greek mythology (the term "spartan" appears in the code), while the underlying credential-stealing and self-propagating mechanics remain substantially identical. Wiz notes the similarities should be treated as TTP (tactics, techniques, and procedures) overlap rather than definitive attribution — leaving open the possibility of a copycat actor leveraging the publicly available toolkit. The same OIDC-token technique appeared in a documented TeamPCP attack against TanStack earlier in 2026.
Phantom Gyp: The June 3 Escalation
On June 3, 2026, beginning at approximately 7:30 p.m. ET, a new Miasma variant deployed a technique that StepSecurity named Phantom Gyp — compromising 57 packages across 286 or more malicious versions in under two hours.
The mechanism is a significant evasion step forward. Standard security tools that monitor npm lifecycle scripts watch preinstall and postinstall hooks in package.json. Phantom Gyp bypasses both by weaponizing binding.gyp, a configuration file ordinarily used by packages with native Node.js add-ons. A 157-byte malicious binding.gyp file triggers node-gyp execution at install time without touching the package.json scripts field — meaning tools monitoring only lifecycle scripts see nothing unusual.
The largest victim was @vapi-ai/server-sdk, the official server SDK for the Vapi.ai voice AI platform, with over 408,000 monthly downloads. It was compromised first, at approximately 11:30 p.m. UTC on June 3. Within an hour, attackers had pushed malicious updates to 50 additional packages maintained by developer jagreehal, including ai-sdk-ollama with over 120,000 monthly downloads. Snyk is tracking the incident as Node-gyp Supply Chain Compromise — June 2026, covering the affected packages at Critical severity. Wiz Research published a dedicated advisory covering the Phantom Gyp wave on June 4 at 5:20 a.m. ET.
What Affected Organizations Must Do Now
Security teams that installed any @redhat-cloud-services package on June 1, or any of the identified Phantom Gyp packages on June 3, should treat their environments as actively compromised and take the following steps immediately.
Rotate all credentials — GitHub tokens, npm tokens, AWS, GCP, and Azure access keys, HashiCorp Vault tokens, Kubernetes service account tokens, SSH keys, and any secrets accessible from the affected CI/CD environment. Removing the package or deleting node_modules is not sufficient cleanup; the malware includes background execution and developer-tool persistence mechanisms.
Audit CI/CD pipeline logs for unauthorized publish events, unexpected OIDC token requests, or newly created repositories in your organization's GitHub namespace. Check package-lock.json and build logs to determine whether any affected version was installed in the relevant window.
For the Phantom Gyp wave, also scan for unexpected binding.gyp files and unexpected node-gyp invocations in build logs, as standard preinstall-script monitors will not flag the Phantom Gyp vector.
Review npm publish access organization-wide: restrict which accounts and pipelines hold publish rights to production namespaces, enforce branch protection rules that require code review before Actions workflows can execute, and apply the principle of least privilege to id-token: write permissions in all workflow files.
Wiz customers can access a dedicated threat advisory through the Wiz Threat Center.
A Worsening Ecosystem Pattern
Miasma is the latest wave in a string of npm supply chain attacks that have grown markedly more sophisticated through 2026. Earlier campaigns in the Shai-Hulud lineage targeted Axios, Aqua Trivy, Checkmarx KICS, Bitwarden, SAP, TanStack, and the GitHub and Nx Console ecosystems. A separate campaign, Megalodon, injected malicious GitHub Actions workflows to harvest CI/CD secrets across public repositories.
The consistent thread is a shift from opportunistic typosquatting toward targeted compromise of trusted, high-value namespaces — made possible by credential theft, OIDC pipeline hijacking, and the open-sourcing of sophisticated attack toolkits that any competent actor can adapt. The Phantom Gyp technique demonstrates that defenders who added preinstall-script monitoring after earlier waves face an attacker who has already moved to a new execution vector.
For organizations relying on package provenance attestations as their primary supply-chain control, Miasma is a structural reminder: a signed certificate proves a package was built by a pipeline. It does not prove the pipeline was clean.
Frequently Asked Questions
What is the Miasma npm supply chain attack?
Miasma is a credential-stealing worm that was injected into 32 official Red Hat @redhat-cloud-services npm packages on June 1, 2026. A Red Hat employee's GitHub account was compromised and used to push malicious code through the CI/CD pipeline, producing backdoored packages with valid cryptographic attestations. The worm fires automatically at npm install, harvests cloud credentials and developer secrets, and attempts to spread itself by republishing packages from any npm account it can reach.
How do I know if my environment was affected by the Red Hat npm compromise?
Check your package-lock.json and build logs for any @redhat-cloud-services package installed on June 1, 2026, or any of the packages identified in the June 3 Phantom Gyp wave. If any affected version was installed, treat all GitHub tokens, npm tokens, cloud credentials, SSH keys, and CI/CD secrets in that environment as compromised and rotate them immediately. Removing the package or deleting node_modules is not a sufficient remediation step.
What credentials does the Miasma worm steal?
Miasma targets GitHub tokens and personal access tokens, npm publishing tokens, AWS, GCP, and Azure cloud credentials, HashiCorp Vault tokens, Kubernetes service account tokens and kubeconfig files, SSH private keys, Docker registry credentials, GPG keys, and .env files. The June 2026 variant added dedicated collectors for GCP and Azure cloud identities, going beyond secret extraction to enumerate all cloud access the infected machine holds.
What is the Phantom Gyp technique and why is it harder to detect?
Phantom Gyp is an evasion method first identified by StepSecurity in the June 3, 2026 Miasma wave. Instead of using the preinstall or postinstall lifecycle hooks in package.json — the fields most security tools monitor — the attacker places a weaponized 157-byte binding.gyp file in the package. This file triggers node-gyp to execute attacker-controlled code during npm install without touching any monitored script field, bypassing conventional install-script security checks entirely.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
