Miasma Is Back: npm Supply Chain Worm Drops binding.gyp Execution to Bypass Postinstall Monitoring

Executive Summary

Three days after the June 1 Red Hat Cloud Services compromise, the Miasma npm worm is back with a second wave. This time it targets @vapi-ai/server-sdk (71,000 weekly downloads), ai-sdk-ollama (31,000 weekly downloads), and 55 other packages, with 647,204 total monthly downloads in scope. First infection confirmed at 02:46:12 +0800 on June 4, 2026. Over 118 GitHub repositories already contain stolen credentials.

The payload itself is unchanged. Same four-layer obfuscation. Same Bun-executed implant. Same credential sweep across AWS, GCP, Azure, GitHub, npm, SSH, and Kubernetes. Same worm propagation using stolen tokens with bypass_2fa: true. What changed is the delivery mechanism, and that change is deliberate.

Wave 1 used a preinstall lifecycle script in package.json. After public reporting on that technique, defenders started tuning scanners and monitoring rules around the scripts field. Wave 2 drops preinstall entirely and routes execution through a preconfigured binding.gyp file. node-gyp processes binding.gyp to compile native addons. The malware fires during that compilation step, before any application code runs, and outside the detection surface of tools that inspect package.json lifecycle hooks. The threat actor pivoted within 72 hours of public disclosure. That is the operational context for everything else in this report.

No CVE exists for any compromised package in this wave. No GHSA. No OSV record. The full exposure window opened and closed before any advisory database had anything to scan against.

TL;DR for Engineering Teams

Vulnerability Overview

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

Technical Breakdown

Root Cause: The binding.gyp Pivot

npm’s lifecycle system gives package maintainers hooks to run code during install. The most common is postinstall; the most immediate is preinstall. Wave 1 of Miasma used preinstall to execute node index.js before the install completes. After that attack was documented publicly, defenders had a concrete detection target: look for suspicious preinstall and postinstall scripts in package.json.

Wave 2 removes those scripts entirely and adds a binding.gyp file instead.

binding.gyp is the configuration file for node-gyp, npm’s native addon compiler. When npm encounters a package with a binding.gyp file, it invokes node-gyp to compile the declared native module from C++ source. This is expected, legitimate behavior for packages like bcrypt, argon2, or serialport that genuinely need native code. The malware authors exploited that expectation: a malicious binding.gyp can direct node-gyp to execute arbitrary code during compilation, and the result is functionally indistinguishable from a legitimate native build step until you look at what the build step actually does.

The operational effect is the same as preinstall: execution fires before npm install completes, before any application code runs, and before the developer or CI system has any indication something went wrong. The detection path is different. Scripts that parse package.json for suspicious lifecycle hooks see nothing, because there are no lifecycle hooks.

The threat actor pivoted from lifecycle-script delivery to node-gyp delivery within 72 hours of Wave 1 public disclosure. The payload, credential targets, and worm propagation logic are unchanged — those were never the thing being detected.

Obfuscation Stack

Exploit Path

Step 1 — Entry. The attacker publishes backdoored versions of 57 npm packages containing a malicious binding.gyp. When a developer or CI runner executes npm install on any of the affected versions, node-gyp is invoked to process the binding.gyp file.

Step 2 — Trigger. The binding.gyp configuration directs node-gyp to execute the payload during the native compilation step. The four-layer obfuscated JavaScript payload launches. At runtime, the decrypted Bun binary is staged to /tmp/b-*/bun and the main implant to /tmp/p{random}.js, executed, then deleted.

Step 3 — Execution. On CI runners, the implant queries the GitHub Actions runtime API using ACTIONS_RUNTIME_TOKEN, enumerates secrets marked isSecret: true, and reads their values directly from /proc/{pid}/mem of the Runner.Worker process. These are masked secrets that never appear in workflow logs. The credential sweep covers 30+ paths: AWS, GCP, Azure, HashiCorp Vault, Kubernetes, npm, SSH, Docker, and all .env variants. Stolen npm tokens with bypass_2fa: true publish backdoored versions to every package the victim account can push. On developer workstations, the process daemonizes and injects persistence before continuing.

Campaign Timeline

Affected Versions

Primary high-download targets:

Total: 57 packages, 286 IOC version entries. Full version list in miasma-wave2-campaign-config.json.

Exposure Analysis

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

Real-World Impact

The worm propagation mechanism makes 57 compromised packages a floor, not a ceiling. Every npm account that installed an affected version and held publish access to additional packages is a potential secondary source. The actual count of malicious versions now circulating on npm may exceed what the initial disclosure captured.

Over 118 GitHub repositories already contain commit artifacts from stolen credentials. The fallback exfiltration channel writes results-{timestamp}-{counter}.json commits with the message prefix IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner:{token}, routing data through api.github.com to bypass egress controls that block novel external endpoints. Those commits are forensic evidence that credentials are already in attacker hands before an organization detects the infection.

Developer workstation persistence is the detail most teams underestimate. The Claude Code SessionStart hook in ~/.claude/settings.json fires every time a developer opens Claude Code. The VS Code folderOpen task in .vscode/tasks.json fires when they open any project. Neither path is cleaned by npm uninstall. A developer who removes the compromised package and considers the incident closed is still running active attacker code.

The @vapi-ai and ai-sdk-ollama packages target AI/voice application developers. The autotel-mcp, executable-stories-mcp, and autotel-mcp-instrumentation packages extend reach into AI coding assistant contexts. The MCP package targeting is consistent with Wave 1’s deliberate inclusion of Red Hat’s hcc-*-mcp packages and reflects a specific interest in accessing AI toolchain credential and filesystem contexts.

Detection Guidance

Host and Process Indicators

Network Indicators (during npm install)

Phoenix Malware Intelligence Detection

Phoenix Security’s malware intelligence platform at phxintel.security/malware.html surfaces behavioral signals regardless of CVE assignment. For Miasma Wave 2, CS-002 (install-hook-abuse) fires on binding.gyp-based invocation. RS-001 (credential-harvesting) fires when the static scanner indexes credential access patterns before runtime decryption. NS-002 (payload-download) and NS-004 (http-post-exfiltration) fire on network activity patterns.

A key principle from Wave 1 analysis applies here: a low heuristic score does not mean low risk. Payload severity is identical across all 57 packages regardless of how much of the obfuscated code the static scanner indexes before runtime decryption. Score 16 and score 92 packages carry the same credential-stealing implant.

Verification Steps for Teams

1. Search all package-lock.json, yarn.lock, pnpm-lock.yaml, and npm-shrinkwrap.json files across all repositories for packages matching the IOC list at compromised versions. Full version list in miasma-wave2-campaign-config.json.
2. Check CI logs for any workflow that ran npm install on or after June 4, 2026, 02:46 UTC and resolved any affected package version.
3. On developer workstations, check for tmp.0987654321.lock, files matching /tmp/p*.js, and Bun binaries in /tmp/b-* directories.
4. Search GitHub organization activity for commits containing IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner.
5. Audit ~/.claude/settings.json for unexpected SessionStart entries on every developer machine that could have installed an affected package.
6. Check .vscode/tasks.json in all project directories for unexpected folderOpen tasks.
7. Run SBOM analysis across container images built after June 4, 2026, for affected package versions.

Remediation Guidance

Immediate Actions

8. Set npm config set ignore-scripts true on all CI runners. This blocks preinstall/postinstall lifecycle hooks. See the note below before deploying globally — it does not fully address binding.gyp delivery in all environments.
9. Pin all lockfiles to versions prior to June 4, 2026, for affected packages. Remove compromised versions from CI runner package caches and private registry proxies.
10. If any affected version was installed: rotate all of the following on every environment that ran the install: GitHub PATs and fine-grained tokens, npm publish tokens, AWS access keys, GCP service account keys, Azure service principal credentials, HashiCorp Vault tokens, Kubernetes service account tokens, SSH private keys, Docker registry credentials.
11. Manually remove persistence artifacts from developer workstations: delete unexpected SessionStart hooks from ~/.claude/settings.json and unexpected folderOpen tasks from .vscode/tasks.json in all project directories. Remove tmp.0987654321.lock and /tmp/b-* Bun directories.
12. Revoke and audit GitHub Actions OIDC Trusted Publishing bindings for any packages hosted in repositories that may have been reached by the worm. Do not re-establish federation until the publish chain is confirmed clean.

IMPORTANT — The limits of –ignore-scripts: npm config set ignore-scripts true reliably blocks scripts.preinstall and scripts.postinstall. It does not universally prevent node-gyp in environments with legitimate native addons. The stronger control is a private registry proxy with a binding.gyp inspection step and an allow-list of packages permitted to invoke node-gyp. This addresses both Wave 1 and Wave 2 delivery mechanisms in a single control.

Mitigations if Lockfile Pinning Is Delayed

• Deploy network egress controls on CI runners, restricting outbound connections during npm install to registry endpoints only.
• Add npm package cooldown enforcement via a private registry proxy: newly published versions require a review window before being served to pipelines.
• Use StepSecurity Harden-Runner in audit mode to capture and alert on unexpected runtime processes and network activity during builds.
• Monitor for the firedalazer commit trigger in repositories the threat actor may have access to. Stage 5 dropper logic is present in the payload but currently dormant.

MITRE ATT&CK Mapping

Phoenix Security Platform Recommendations

The zero-CVE gap is not a theoretical concern for this campaign. All 57 compromised packages were published without triggering any CVE, GHSA, or OSV assignment. Teams relying on scanner workflows that gate on vulnerability database lookups had no signal during the active exposure window.

Phoenix Security’s malware intelligence platform at phxintel.security/malware.html detected Miasma packages through behavioral signal analysis within minutes of publication. CS-002 (install-hook-abuse) fires on both lifecycle-script and binding.gyp delivery because it analyzes execution triggers broadly rather than matching a specific package.json field.

Reachability analysis identifies which build environments actually executed an affected package’s install hook versus environments that listed the package as a dependency but installed from a pre-compromise cache. When scoping credential rotation, that distinction is operationally significant. Rotating credentials for 300 CI runners when 30 actually ran the payload wastes incident response time; missing any of those 30 leaves access open.

Remediation campaigns track the multi-step response across engineering teams: lockfile updates per repository, credential rotation completion per environment, persistence artifact cleanup per developer machine, OIDC rebinding confirmation per package, and container image rebuilds per registry. Without that tracking, teams finish the easy parts and lose visibility on the tail.

Attack surface management surfaces which pipelines and build environments pull from the affected namespaces, giving the security team a complete organizational exposure map rather than waiting for individual teams to self-report.

Campaign config, IOC scanner, and CISO brief for MIASMA_WAVE2_BINDINGYP_2026 are available at phxintel.security/package.html.

Download Phoenix Security campaign config.

Protect yourself with the latest threat intelligence, get access to PHOENIX BLUE Today

External References

1. Socket Security — Miasma Supply Chain Attack Is Back on npm, over ~600,000 Monthly Downloads Affected (Moshe Siman Tov Bustan, Nir Zadok, June 4, 2026) — primary Wave 2 technical source
2. Phoenix Security — MIASMA_WAVE1_REDHAT_2026 campaign analysis
3. StepSecurity — Malware in @redhat-cloud-services npm Packages: Runtime Analysis (June 1, 2026)
4. Phoenix Security — Mini Shai-Hulud / TeamPCP: TanStack and Mistral Campaign (May 2026)
5. Phoenix Security — Sha1-Hulud reverse engineering and persistence IOCs
6. Phoenix Security Malware Intelligence Platform
7. Phoenix Security Campaign IOC Tracker
8. Phoenix Security Open-Source npm Scanner
9. StepSecurity disclosure — RedHatInsights/frontend-components Issue #2329
10. StepSecurity disclosure — RedHatInsights/javascript-clients Issue #492