Miasma Worm 73: Inside the Microsoft/GitHub Supply Chain Attack Targeting 73 Tech Organisations

Miasma did not emerge in a vacuum. It traces directly to TeamPCP's publicly released Mini Shai-Hulud worm prototype from mid-May 2026. What started as a proof-of-concept evolved into a fully operational threat actor tool over three weeks, absorbing lessons from a previous run against 32 Red Hat npm packages.

• 1Mid-May 2026: TeamPCP publicly releases Mini Shai-Hulud worm prototype. Core innovation: using binding.gyp to trigger execution during npm install without touching package.json scripts.
• 2Late May 2026: Miasma variant mutates, targeting 32 @redhat-cloud-services npm packages across 90+ versions. Campaign compromises TanStack, Mistral AI, and UiPath npm packages. Total infected packages reach 57, spanning 286+ versions.
• 3June 1–4, 2026: Microsoft Security Blog documents the Red Hat npm campaign in detail. GitHub begins notifying affected maintainers. Worm propagation continues into new ecosystems including PyPI and RubyGems.
• 4June 5, 2026 (07:30 UTC est.): Miasma reaches Microsoft's Azure/durabletask repository via a previously compromised contributor account. Malicious commit plants .claude/setup.mjs and .cursor/rules/setup.mdc backdoor files alongside a 4.3 MB payload runner.
• 5June 5, 2026 (07:31:45 UTC est.): GitHub's automated systems trigger. Within a 105-second window, 73 repositories across Azure, Azure-Samples, Microsoft, and MicrosoftDocs organizations are disabled. GitHub notifies Microsoft security teams.
• 6June 6, 2026: StepSecurity, The Hacker News, and thenextweb report the incident publicly. GitHub confirms the campaign marker "Miasma: The Spreading Blight" embedded in payload and repo descriptions. C2 account github.com/liuende501 with 236 credential dead-drop repositories identified.

Every npm security scanner worth its salt monitors preinstall, postinstall, and install scripts inside package.json. Miasma bypasses all of them by abusing binding.gyp — a file used by Node's native addon build system (node-gyp) to compile C/C++ extensions. When node-gyp processes this file, it evaluates embedded shell commands through GYP's command substitution syntax.

• 1Miasma plants a binding.gyp file with a single malicious entry in the sources array using GYP command substitution: "<!(node index.js > /dev/null 2>&1 && echo stub.c)"
• 2When a developer runs npm install, node-gyp processes binding.gyp to build the native addon. It evaluates the <!() expression, executing node index.js — the malicious payload — as a side effect of "compiling."
• 3The malicious index.js is placed at the package root (not dist/index.js), weighing in at 4+ MB — a clear anomaly detectable by build artifact scanning.
• 4Stderr is redirected to /dev/null and execution is chained with && echo stub.c to return a valid stub source file name, making the build appear normal to node-gyp.

Miasma's payload is protected by four nested obfuscation layers, each designed to defeat a different class of static analysis. The final decrypted payload runs inside a Bun JavaScript runtime — not Node.js — specifically to evade Node-focused security monitoring tools deployed in most CI/CD pipelines.

• 1Stage 0 — Preinstall Bootstrap: A 4.29 MB dropper is embedded in the malicious package. The binding.gyp trigger executes node index.js, which loads this dropper without any user-visible output.
• 2Stage 1 — ROT-N Caesar Cipher: Character-code arrays are decoded with variable rotation values (ROT-9 through ROT-20 observed across versions). Dynamically executed via eval(). Purpose: defeats simple string-matching signatures.
• 3Stage 2 — AES-128-GCM Encryption: Two encrypted blobs with embedded keys, IVs, and auth tags. After decryption, the payload downloads the Bun v1.3.13 JavaScript runtime from official Bun GitHub releases, then executes the main payload via Bun to bypass Node.js-focused monitoring.
• 4Stage 3–4 — Obfuscator.io + PBKDF2: A 668 KB main malware module with a 2,306-entry encrypted string table. Protected with custom PBKDF2-HMAC-SHA-256 (200,000 iterations) to make decryption computationally expensive for sandboxes. Process execution chain: node → shell → bun → payload.

Miasma's credential harvester is comprehensive. It targets every cloud platform and developer tool a typical CI/CD runner might have access to. Particularly notable is the GitHub Actions runner process memory scraping technique, which extracts masked secrets that would otherwise never appear in logs.

Miasma uses three distinct exfiltration channels simultaneously. Channel A drops stolen credentials to GitHub dead-drop repositories. Channel B injects worm source code into accessible repositories for propagation. Channel C — currently dormant — uses api.anthropic.com as a swappable live exfiltration endpoint.

• 1Creates a new public repository in the compromised developer's GitHub account. Repository description contains campaign marker: "Miasma: The Spreading Blight".
• 2Commits stolen credentials as RSA-encrypted JSON to results/results-{timestamp}.json. Repository names follow pattern {adjective}-{creature}-{0–99999} (e.g., nemean-hydra-34343).
• 3Primary C2 collection account: github.com/liuende501 with 236 programmatically-created credential storage repositories. Stolen tokens double-Base64 encoded in transit. Traffic spoofs python-requests/2.31.0 User-Agent.
• 4C2 rotates across a pool of 16 attacker-controlled GitHub accounts per session. This distributes the data collection and complicates takedown efforts.

• 1Enumerates all accessible repositories via /user/repos and /user/orgs using stolen GitHub tokens.
• 2Injects worm source code as .github/setup.js, .claude/setup.mjs, and .cursor/rules/setup.mdc into non-protected repository branches via the Git Data API (blob → tree → commit → ref update).
• 3Skips protected branches, default branches named main/master where protection is detected, and bot-owned repositories. Spoofs commit identity using [email protected] to blend with automated CI commits.
• 4Forges SLSA provenance attestations through Sigstore (Fulcio/Rekor) and republishes poisoned npm packages using stolen npm OIDC tokens with fraudulent provenance metadata.

• 1Audit npm packages installed in the last 30 days against the compromised package list. Check for any @redhat-cloud-services/*, @vapi-ai/server-sdk, ai-sdk-ollama, or autotel family packages in your lockfiles.
• 2Search all repositories for Miasma backdoor files: .claude/setup.mjs, .cursor/rules/setup.mdc, .github/setup.js. These files were planted by the worm propagation module in any repo accessible to stolen tokens.
• 3Check for anomalous binding.gyp files: Any binding.gyp containing <!(node or node index.js in the sources array is malicious. Legitimate native addons reference C/C++ source files, not JavaScript.
• 4Audit GitHub public repositories created by any organizational members in the last 60 days. Look for repos with descriptions matching "Miasma: The Spreading Blight" or with results/ directories containing JSON files.
• 5Review Bun runtime downloads in build system logs. Any curl or wget fetching from github.com/oven-sh/bun/releases during an npm install operation indicates compromise.

If compromise is confirmed, credential rotation must follow a specific sequence to avoid triggering the destructive honeytoken wiper. Rotate in this order to minimize blast radius.

• 1FIRST — Identify honeytoken: Before revoking ANY GitHub tokens, check each token against the IOC list. The token IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner is a named honeytoken that triggers destructive wiper on revocation. Isolate machines that may execute it before touching tokens.
• 2Cloud credentials (AWS/Azure/GCP) first: These are the highest-value targets and have no honeytoken risk. Rotate all IAM keys, managed identity tokens, and service account credentials immediately. Invalidate all active sessions.
• 3GitHub tokens: After confirming no honeytoken exposure, revoke compromised GitHub tokens via Settings → Developer settings → Personal access tokens. Audit OAuth app authorizations.
• 4npm tokens: Revoke all npm publish tokens. Audit any packages published in the past 30 days for version tampering. Compare against official checksums.
• 5CI/CD secrets: Rotate all GitHub Actions secrets, CircleCI environment variables, and SSH deploy keys. Re-evaluate secret scope — CI secrets should never have write access to production.

• 1Preserve build logs from all CI/CD systems for the relevant time window. Look for the node → shell → bun execution chain. GitHub Actions: navigate to the workflow run and export full logs before they expire (default 90 days).
• 2Capture network logs from build agents. Key outbound destinations: api.github.com, github.com/oven-sh, 169.254.169.254 (IMDS), 169.254.170.2 (Azure IMDS), metadata.google.internal.
• 3Snapshot the compromised package versions from npm cache before clearing. The malicious index.js files (SHA-256 hashes in Phase 7) are valuable for malware analysis and legal holds.
• 4Audit git history of all repositories for commits from [email protected] that introduced .claude/, .cursor/, or .github/setup.js files. These commits should not exist in repos without GitHub Actions workflows that produce them.
• 5Check liuende501 GitHub account for repositories containing your organization's secrets. If found, this is evidence of exfiltration. Do not delete — preserve as evidence and report to GitHub Trust & Safety.