The Miasma attack on June 1, 2026 was not a single exploit. It was a chain of three compounding mechanisms that each addressed a different barrier between an attacker and a production developer environment. Understanding what happened requires understanding each link separately: how a GitHub OIDC token becomes an npm publish credential, why preinstall scripts execute without developer awareness, and how a worm self-propagates through a package registry.
The OIDC Token as a Publish Credential
GitHub Actions can authenticate to external services without storing static credentials. The mechanism is OpenID Connect. When a workflow runs, GitHub's OIDC provider issues a short-lived JSON Web Token signed by GitHub, identifying the repository, workflow name, and branch. An external service — in this case npm's publish endpoint — accepts that token in place of a stored API key, verifies the signature directly against GitHub's public key set (JWKS) and evaluates the token's claims against the repository's configured publishing policy.
This was the design intent: replace long-lived tokens with ephemeral, auditable credentials. The attack turned this mechanism against the repository owner. The attacker pushed orphan commits to three RedHatInsights repositories, each containing a minimal workflow with id-token: write permissions. GitHub's runner issued a valid OIDC token for the repository identity. That token had publish rights to every @redhat-cloud-services package associated with those repositories. The obfuscated _index.js payload consumed the token and published 32 backdoored package versions, each carrying a valid SLSA provenance attestation because they were published through GitHub's infrastructure.
The commits bypassed code review because they were pushed as orphan branches — branches with no commit history connected to the main branch. Pull request requirements and branch protection rules apply to branches that affect deployment targets; an orphan branch that exists only long enough to trigger a workflow does not necessarily trip those controls depending on how repository rules are configured.
Install-Time Execution
npm packages can declare scripts that execute automatically at defined points in the package lifecycle. The preinstall hook runs before the package contents are written to node_modules, meaning it runs before a developer has seen or reviewed any of the package's actual code. This capability exists to handle legitimate setup tasks — compiling native bindings, checking system dependencies — but it provides an execution point with no additional prompt or confirmation.
Miasma used a preinstall hook to invoke an obfuscated JavaScript file included in the package payload. The obfuscation used layered eval() calls with ROT-based string encoding to conceal functionality from static analysis. From the perspective of a developer running npm install, the hook fires silently. From the perspective of the payload, it has immediate access to the developer's filesystem, environment variables, and any credentials stored in the standard locations for GitHub, npm, AWS, GCP, and Azure tooling.
The choice of preinstall over other hooks matters for two reasons. First, timing: preinstall fires before the final node_modules tree is written and before lockfile generation completes, meaning SAST tools and filesystem scanners that trigger on those final write events have not yet instrumented the package. Second, noise tolerance: preinstall is the conventional home for legitimate native compilation tasks — node-gyp binding builds, OS-level setup scripts — so EDRs and behavioral monitors apply higher thresholds to unusual activity at that hook because unusual activity is normal there. The payload hides in the same execution window that ships with every package that compiles a C++ binding.
Worm Propagation Through the Registry
Credential theft alone produces a static set of stolen secrets. The Miasma payload extended its reach by turning stolen npm tokens into a propagation vector. After exfiltrating initial credentials, the payload queries npm's registry API for all packages the compromised identity has publish access to. It then publishes backdoored versions of each of those packages, embedding the same payload and repeating the query from each newly infected context.
This is the worm mechanic: each infection produces new publish credentials, and those credentials access a different segment of the registry's package graph. A single compromised developer account with broad publish rights — common in large open-source organizations where contributors maintain many packages — can seed dozens of downstream infections in a single execution cycle.
Miasma introduced a per-infection payload encryption step absent in earlier Mini Shai-Hulud variants. Each published version receives a uniquely encrypted version of the payload. Hash-based detection — matching known-malicious file hashes against package contents — fails against this approach because no two infections produce identical binary artifacts. Detection requires behavioral analysis of the payload's actions rather than pattern matching against prior samples.
What Open-Sourcing the Tooling Changed
TeamPCP published the Mini Shai-Hulud source code on May 12, 2026. That release did not introduce new capabilities into the threat landscape. It removed the capability barrier. The attack techniques used in Miasma — OIDC token abuse, install-time hooks, worm propagation through the registry — were already known to the security community from prior TeamPCP campaigns. What changed is that executing those techniques no longer requires the operational knowledge TeamPCP accumulated over months of active campaigning. Any actor who can read the source and configure a GitHub account can now run a structurally equivalent campaign.
Attribution for Miasma remains unconfirmed. The tradecraft matches TeamPCP TTPs. It also matches what any actor could produce by following the published code. That ambiguity is a direct consequence of the open-source release, and it is likely permanent for any subsequent campaign using the same tooling.