Miasma: The Spreading Blight - How a Stolen GitHub Cookie Poisoned 32 Red Hat npm Packages

Published: June 4, 2026
Tags: Supply Chain, npm, Credential Theft, CI/CD Security, T1195.002

Introduction

On June 1, 2026, a credential-stealing worm quietly embedded itself into 32 officially published packages under Red Hat's @redhat-cloud-services npm namespace. By the time security researchers noticed and began pulling malicious versions, those packages had already accumulated roughly 80,000 weekly downloads across 96 poisoned versions. By June 3, a second wave had spread the same worm to 57 more packages across entirely separate maintainer ecosystems, including the official Vapi.ai server SDK with over 408,000 monthly downloads.

The campaign has been named Miasma, after a string the malware stamps onto attacker-created GitHub repositories: "Miasma: The Spreading Blight." The name fits. This is not a targeted intrusion against a single organization. It is a self-replicating supply chain worm, and the infection vector was not a zero-day or a clever bypass. It was a session cookie stolen from a developer's personal device by an infostealer, sitting undetected in a criminal marketplace for seven weeks before anyone used it.

This article covers what happened, how the malware works, why it is harder to detect than previous supply chain attacks, and what defenders can do right now.

The Seven-Week Head Start

The most important part of the Miasma story is not what happened on June 1. It is what happened on April 13.

Dark web monitoring firm Whiteintel, reviewing its infostealer log archive after the Miasma disclosure, found that the Red Hat employee's GitHub credentials and active session cookie had already been harvested and sold before the attack ever took place. The credentials first appeared in infostealer logs on April 13, 2026, and again on May 15, 2026. The attacker did not need to brute-force anything. They did not phish anyone on the day of the attack. They purchased access that had been sitting in a criminal marketplace for nearly two months.

This is the part of the story that should concern every security team regardless of whether Red Hat packages are anywhere near your environment. The credential theft and the exploitation are separated by weeks. By the time defenders have an incident to respond to, the exposure window has already been open for a long time. Dark web telemetry and infostealer log monitoring are not optional threat intelligence sources. For organizations with developers publishing to public registries, they are table stakes.

How the Attack Was Carried Out

With valid GitHub credentials and a live session cookie in hand, the attacker accessed the compromised Red Hat employee account and pushed malicious orphan commits to three repositories inside the RedHatInsights GitHub organization:

• RedHatInsights/frontend-components
• RedHatInsights/javascript-clients
• RedHatInsights/platform-frontend-ai-toolkit

The commits bypassed code review entirely. Each commit introduced a minimal GitHub Actions workflow that triggered on push to any branch and requested a GitHub OIDC token with id-token: write permissions. That token was then passed to an obfuscated payload (_index.js) that published Trojanized package versions to npm.

The result: malicious packages shipped with valid SLSA provenance attestations. The packages really were built by Red Hat's pipeline. The pipeline did exactly what it was designed to do. The problem was that malicious code had been injected into the build before the pipeline ran. This is a critical distinction because SLSA attestations, which are increasingly used as a trust signal for supply chain security, provide no protection once the source repository itself has been tampered with.

The attack occurred in two waves, with the second wave beginning at 13:44 UTC on the same day, introducing additional poisoned versions before the first set of revocations was complete.

The Payload: A Worm Derived from Mini Shai-Hulud

Miasma is not original malware. It is derived from Mini Shai-Hulud, a supply chain worm that was open-sourced by a group known as TeamPCP in May 2026. The modifications are largely cosmetic. Dune universe references were replaced with Greek mythology theming, a few new data collectors were added, and the payload delivery was made significantly harder to track. The core tradecraft is the same.

What the malware does, step by step:

1. Execute at install time. The initial wave used a preinstall hook in package.json to automatically run a malicious index.js during npm install. No user interaction required. No warning displayed.

2. Harvest credentials across every environment it touches. The payload collects:

• npm tokens
• GitHub Personal Access Tokens (PATs) and session cookies
• AWS credentials (~/.aws/credentials, environment variables)
• GCP service account identities (new in this variant)
• Azure managed identities and service principals (new in this variant)
• HashiCorp Vault tokens
• Kubernetes service account tokens
• RubyGems credentials
• CircleCI tokens

The addition of GCP and Azure identity collectors marks a notable evolution from prior variants, which focused primarily on extracting static secrets. This variant appears oriented toward gaining persistent cloud access, not just stealing credentials for resale.

3. Propagate. The worm uses the harvested npm tokens and GitHub PATs to publish poisoned versions of other packages the victim maintains, spreading itself to new namespaces and maintainer accounts. It also injects malicious steps into existing GitHub Actions workflow files in any repository it can access, ensuring the payload runs on every future CI job.

4. Evade hash-based detection. Unlike previous variants, Miasma generates a uniquely encrypted payload for each infection. This makes hash-based IOCs reliable only for a specific package version. Defenders who rely solely on file hashes to identify this malware will miss subsequent waves.

The "Phantom Gyp" Technique

By June 3, as security tooling began catching the preinstall hook pattern, the attacker introduced a new execution technique that StepSecurity researchers named "Phantom Gyp."

Most security tools monitoring npm supply chain attacks focus on preinstall and postinstall scripts in package.json. npm's own audit systems flag suspicious entries in these hooks. Code reviewers have been trained to look for them.

This technique avoids all of that. Instead of modifying package.json scripts, the attacker adds a binding.gyp file to the package. When npm encounters a binding.gyp file, it automatically invokes node-gyp to compile native addons. That compilation process executes the content of binding.gyp during npm install without touching the lifecycle script fields that defenders watch. The malicious payload runs silently, and most current tooling does not flag it.

This technique is significant because it represents a direct evolutionary response to defensive tooling. The attacker observed what was being detected and adapted within days. Any detection strategy that relies exclusively on monitoring preinstall/postinstall hooks is now incomplete.

Scale and Affected Packages

Wave 1 (June 1, 2026): At least 32 package releases under @redhat-cloud-services were affected, including:

• @redhat-cloud-services/topological-inventory-client
• @redhat-cloud-services/compliance-client
• @redhat-cloud-services/rbac-client
• And dozens more across the namespace

Most malicious versions were revoked by 1PM UTC. Two remained live at the time of initial reporting.

Wave 2 (June 3, 2026): The worm's self-propagation mechanism kicked in. 57 packages across 286+ malicious versions were identified across entirely new maintainer accounts, including:

• @vapi-ai/server-sdk (408,000+ monthly downloads)
• ai-sdk-ollama by maintainer jagreehal (120,000+ monthly downloads)
• Packages across the autotel, awaitly, executable-stories, node-env-resolver, and wrangler-deploy families

Attribution

Wiz Research attributed the tradecraft to TeamPCP, the group behind the Mini Shai-Hulud campaign. However, because TeamPCP publicly released the source code and methodology for Mini Shai-Hulud, attribution cannot be treated as definitive. Other actors can and likely are using the same open-sourced tooling. The similarities observed in Miasma should be treated as TTP overlap rather than confirmation of a single actor.

MITRE ATT&CK Coverage

Indicators of Compromise

Per Wiz Research, the following commit SHAs are associated with the malicious orphan commits:

Behavioral indicators:

• Presence of binding.gyp in pure JavaScript packages with no native addon requirement
• preinstall hooks invoking index.js with no corresponding build step
• GitHub Actions workflows requesting id-token: write on branches that do not require publishing
• Obfuscated JavaScript using eval() with ROT-based string decoding
• Repository descriptions containing the string "Miasma: The Spreading Blight"
• Unexpected access to ~/.aws/credentials, ~/.npmrc, or Kubernetes service account token paths at install time

Note: Because the worm generates a uniquely encrypted payload per infection, file hashes are unreliable as a primary detection method. Behavioral and process-based detection is required.

What Defenders Should Do Now

If you run npm packages in your environment:

Audit your full dependency tree, including transitive dependencies, for any @redhat-cloud-services packages. Transitive dependencies are the biggest exposure here. Many organizations affected by this attack did not know they depended on these packages because they sit several layers deep in their build trees.

If any affected package was installed between May 31 and June 4, 2026, treat the environment as compromised and rotate:

• npm tokens
• GitHub Personal Access Tokens
• AWS access keys and roles
• GCP service account credentials
• Azure service principals
• HashiCorp Vault tokens
• Kubernetes service account tokens

Suspend and review any CI/CD artifacts, container images, or release artifacts produced during the exposure window.

For CI/CD hardening:

• Restrict GitHub Actions id-token: write permissions to workflows that explicitly require them, scoped to protected release branches only
• Enforce branch protection rules that require pull request reviews before merging, including from organization members
• Monitor for orphan commits (commits not associated with a pull request) pushed directly to repository branches
• Alert on new GitHub Actions workflows introduced to a repository, particularly those requesting OIDC token permissions
• Flag binding.gyp files appearing in pure JavaScript packages that have no native compilation history

For ongoing supply chain intelligence:

• Subscribe to dark web monitoring feeds that surface developer credentials and session cookies from infostealer logs
• Maintain a live inventory of transitive npm dependencies refreshed frequently enough to detect version changes
• Correlate any credential rotation events with your known dependency exposure windows

References

• Wiz Research: Miasma: Supply Chain Attack Targeting RedHat npm Packages
• StepSecurity: binding.gyp: An npm Supply Chain Attack That Spreads Like a Worm
• Aikido Security: Initial disclosure, June 1, 2026
• Whiteintel: Credential timeline analysis, June 2, 2026
• Red Hat Security Bulletin: RHSB-2026-006
• CybelAngel: Miasma Supply Chain Attack: The Seven-Week Credential Trail
• The Hacker News: Miasma Supply Chain Attack Compromises Red Hat npm Packages
• Unit 42: The npm Threat Landscape: Attack Surface and Mitigations