Miasma 'Phantom Gyp' npm Worm Abuses binding.gyp - 57 Packages, 286 Versions, Vapi.ai SDK Hit

Disclosed in early June 2026, the Miasma worm's 'Phantom Gyp' variant abuses a 157-byte binding.gyp file to trigger code execution during npm install, bypassing scanners that watch only for preinstall and postinstall script abuse in package.json. In a rolling campaign lasting under two hours it compromised 57 npm packages across 286+ malicious versions. This advisory covers what happened with the Miasma binding.gyp npm worm and how to inventory and govern the install-time hook it abuses.

What happened

The Miasma binding.gyp npm worm is a self-replicating supply-chain payload whose 'Phantom Gyp' variant abuses binding.gyp - the build configuration node-gyp reads to compile native add-ons - to run code during npm install. Because the execution vector is a native-build hook rather than a script field, it bypasses scanners that watch only for preinstall and postinstall abuse in package.json. The malicious file is just 157 bytes, and there is no single CVE.

In a rolling campaign lasting under two hours, Miasma compromised 57 npm packages across 286+ malicious versions. It began with 32 packages under the @redhat-cloud-services namespace trojanized on June 1, 2026. The largest victim was @vapi-ai/server-sdk, the official Vapi.ai voice-AI server SDK with 408,000+ monthly downloads, first hit at 23:30 UTC on June 3, 2026. An infected install steals credentials and replicates, seeding further trojanized publishes across the registry.

Miasma exfiltrates without a fixed command-and-control server. The payload creates a new GitHub repository on the fly and uploads stolen secrets as encrypted JSON, using GitHub itself as a dead-drop channel. Exfiltration was traced to the GitHub account liuende501, hosting 236 dead-drop repositories. The worm also crossed into GitHub automation: AI coding-agent hooks planted in Azure/durabletask led GitHub to disable 73 Microsoft repositories within 105 seconds. Remediation requires auditing binding.gyp files in dependencies, pinning versions, and rotating GitHub, npm, and cloud tokens.

Why this is an agentic-endpoint risk

Miasma lives in the layer your other controls were never built to inventory. The execution vector is a build hook in a dependency, and the worm's escalation into AI coding-agent hooks in Azure/durabletask is the same pattern: a hook that runs code on someone else's behalf, on the endpoint, before anyone reviews it. Hooks are one of the eight AI artifact types Anomity tracks per endpoint - alongside AI agents, MCP servers, extensions, skills, plugins, secrets, and CLIs - adopted bottom-up the way AI agents became the new shadow IT.

This exposure is hard to see from the tooling you already run. The npm install looks like ordinary developer activity to network monitoring, node-gyp compiling a native add-on looks legitimate to EDR, and DLP sees nothing at rest because the stolen secrets leave as encrypted JSON to a fresh GitHub repository that resembles routine API traffic. Script-only scanners read package.json lifecycle fields and never open binding.gyp. The question is not whether one package is patched - the worm spans 286+ versions and replicates - it is which endpoints ran an affected install and what those hooks were allowed to do. It shares a root cause with the sibling Shai-Hulud 2 npm worm credential stealer advisory: a self-replicating payload that turns an install hook into credential theft.

How Anomity surfaces and governs it

With a worm that spans hundreds of versions and replicates as it goes, chasing a patched version is not the durable control. Inventory the hooks that run code on your endpoints and govern what they do. Anomity does that in three steps.

First, inventory. Anomity inventories hooks, AI agents, MCP servers, and CLIs on every managed endpoint as part of the eight AI artifact types it tracks, then classifies them - including the AI coding-agent hooks Miasma planted - so you can find every place that runs code on someone else's behalf. Anomity collects metadata only, and secrets such as GitHub, npm, and cloud tokens are redacted on the endpoint before anything leaves it, so a worm reading them at install time has nothing centralized to capture.

Second, decide at the hook. On agents that expose a hook - for example, the Claude Code PreToolUse event - Anomity evaluates each tool call against your policy and returns allow, deny, or log before the call runs. A hook reaching for a credential, spawning a process to compile a native add-on, or pushing to a freshly created GitHub repository can be denied at the boundary - which is what runtime governance provides for a payload that runs before any scanner reviews it, catching the binding.gyp install-time code that script-only scanning misses.

Third, keep the record. Anomity logs the tool calls and secret access an agent performs, so a hook reaching a token or creating a repository is recorded against a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a worm like Miasma lands, you can answer which endpoints ran an affected install and what their hooks were allowed to do - from a record, not a guess. Anomity is SOC 2 Type II and complements your Network, EDR, DLP, and GRC tooling. See how it fits in how it works and how it compares to existing controls.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint and pipeline that ran npm install in the June 1–3, 2026 window, and confirm none pulled an affected @vapi-ai/server-sdk, @redhat-cloud-services package, or any of the 57 trojanized packages.
• Audit binding.gyp files in your dependency tree - including transitive ones - for unexpected build commands, since Phantom Gyp hides execution in the native-build hook, not package.json scripts.
• Pin npm dependencies to known-good versions and verify lockfile integrity, so a worm spanning 286+ versions cannot reach an install through a floating range.
• Rotate GitHub, npm, and cloud tokens reachable from any potentially infected endpoint, and review GitHub for unexpected repositories that could serve as encrypted-JSON dead drops.
• Inventory the install-time and AI coding-agent hooks across your fleet - the surface Miasma abused in Azure/durabletask - using the hook and artifact inventory.
• Confirm install-time and agent hooks are evaluated at a hook with allow/deny/log, so credential reads and pushes to fresh repositories are stopped before they run.
• Verify every tool call and secret access is written to a 90-day audit trail and routed to your SIEM, so you can answer scope when the next npm worm lands.
• Cross-reference this inventory against the sibling Shai-Hulud 2 npm worm credential stealer advisory to find endpoints exposed to more than one install-time path.

Miasma's Phantom Gyp variant is a reminder that install-time execution does not need a script field - a 157-byte binding.gyp and a build hook are enough, and a self-replicating worm turns one infected install into a registry-wide problem. Audit binding.gyp files, pin versions, and rotate GitHub, npm, and cloud tokens, then inventory the hooks your endpoints run and govern what those hooks do at the boundary. For the full picture of these campaigns and how to defend against them, see the pillar guide on AI supply-chain attacks: a defender's guide. To see Anomity govern the hook layer across your fleet, request early access.