In the fast-paced ecosystem of DevSecOps and Application Security (AppSec), defending against software supply chain attacks often feels like hitting a moving target. In June 2026, the cybersecurity landscape was jolted by a highly sophisticated, self-replicating worm dubbed “Miasma.”
In under two hours, Miasma compromised 57 npm packages across hundreds of versions, weaponizing prominent libraries like @vapi-ai/server-sdk which boasts over 408,000 monthly downloads. Unlike conventional malware that relies on easily detectable lifecycle scripts, Miasma introduced a novel evasion mechanism known as “Phantom Gyp.” This attack didn’t just steal multi-cloud credentials; it actively poisoned AI coding assistants and transformed GitHub repositories into dead-drop Command and Control (C2) servers.
For CISOs, Threat Researchers, and SOC analysts, understanding Miasma is no longer optional, it is critical. This comprehensive breakdown explores the inner workings of the Phantom Gyp technique, traces the malware’s explosive kill chain, and provides a definitive step-by-step guide on fortifying your CI/CD pipelines using advanced defense mechanisms, including Axeploit.
Decoding the Miasma Worm: A Supply Chain Nightmare
Supply chain attacks have rapidly evolved from simplistic typosquatting to highly automated, self-propagating threats. On June 3, 2026, an attacker compromised multiple prominent maintainer accounts to deploy a rolling campaign. The speed of the attack was unprecedented. Within a brief two-hour window, the attacker published 286 malicious versions across 57 packages.
The primary target was the widely adopted @vapi-ai/server-sdk, alongside other highly utilized packages like ai-sdk-ollama (which sees over 120,000 monthly downloads) and dozens of packages within the autotel, awaitly, and wrangler-deploy namespaces.
What makes the Miasma worm exceptionally dangerous is its blast radius. Rather than simply executing a cryptominer, Miasma is a highly targeted credential harvester purpose-built for CI/CD environments. It effectively uses the compromised package as an initial access vector to breach the build environment, steal high-privilege tokens, and then use those tokens to infect adjacent systems, codebases, and completely distinct ecosystems.
The “Phantom Gyp” Technique: Bypassing Traditional Defenses
Traditional npm malware typically relies on preinstall or postinstall scripts declared within a package’s package.json file. Because AppSec tooling, Static Application Security Testing (SAST) scanners, and even native npm audit tools are heavily trained to monitor and flag these scripts, attackers needed a new vector. Enter the “Phantom Gyp” technique.
How Phantom Gyp Works
To bypass static lifecycle script monitors, the Miasma threat actors abused node-gyp, a native build tool included with npm that compiles C++ add-ons for Node.js. The attackers completely removed any suspicious preinstall scripts from the package.json. Instead, they planted a tiny, 157-byte file named binding.gyp into the root of the published tarball.
During a standard npm install, if npm detects a binding.gyp file, it automatically assumes the package requires native C/C++ compilation and silently triggers node-gyp rebuild.
The Exploit Mechanism
The actual exploit relies on a flaw in how node-gyp processes shell expansions. The malicious binding.gyp file utilizes gyp's command substitution syntax <!(...) to blindly execute an obfuscated JavaScript file (index.js).
Here is the exact binding.gyp code snippet used in the Miasma attack:
Breaking down the payload execution:
- node index.js: This triggers the execution of the 4.5 MB malicious JavaScript payload hiding in the package root.
- > /dev/null 2>&1: This strictly silences all standard output and error logs, ensuring the CI/CD console remains completely blind to the execution.
- && echo stub.c: This simply returns a fake source filename to the node-gyp process, preventing it from throwing a build error and raising suspicions.
The result is arbitrary code execution right in the middle of an npm install, with zero footprint in the package.json. To static analysis tools, the legitimate application code (housed in the dist/ folder) appears completely clean, while the malicious 4.5 MB index.js silently executes in the background.
The Attack Chain and Worm Behavior: A Deep Dive into Miasma’s Execution
Once the binding.gyp file tricks node-gyp into executing the root index.js, Miasma initiates a highly choreographed sequence. The malware moves from initial execution to credential exfiltration in under 15 seconds, utilizing a four-stage execution chain designed explicitly to bypass Static Application Security Testing (SAST) and blind dynamic Endpoint Detection and Response (EDR) agents.
Stage 1: ROT-N Caesar Cipher and Dynamic Evaluation
To evade signature-based detection, the initial 4.5 MB payload is not heavily obfuscated with standard packers. Instead, the root index.js contains a massive array of approximately 1.3 million character codes wrapped in a single try{eval(...)}catch(e){} block.
The script dynamically decodes these characters using a Caesar cipher function that applies a variable ROT shift.
Crucially, the threat actors varied the ROT shift across the campaign to disrupt static hashing. For example, @vapi-ai/server-sdk@1.2.1 utilized a ROT-9 shift, while executable-stories-demo@0.1.11 used ROT-20. This deliberate polymorphic behavior ensures that security tooling relying on single static signatures fails to flag the variations.
Stage 2: AES-128-GCM Self-Decrypting Layer
Once the initial payload is dynamically evaluated in memory, the script enters its second stage by importing the node:crypto module. It defines an AES-128-GCM decryption helper to decode two inline, hex-encoded blobs.
The cryptographic keys, Initialization Vectors (IVs), and authentication tags are hardcoded directly within the script:
This decryption yields a 907-byte loader script and a massive 668 KB obfuscated main payload.
Stage 3: The Bun Runtime Lateral Shift
To effectively blind process monitoring tools that strictly watch the node process tree during an npm install, the 907-byte loader (Blob 1) acts immediately. It executes a curl command to download a standalone binary of the alternative JavaScript runtime, Bun (specifically bun-v1.3.13/bun-linux-x64-baseline.zip), from GitHub releases.
This download and extraction process is executed in roughly 900 milliseconds. Miasma then writes the 668 KB main payload (Blob 2) to a randomized temporary path (e.g., /tmp/p1764ajw42rg.js) and launches it via the newly downloaded Bun executable (/tmp/b-80596p/bun run /tmp/p1764ajw42rg.js). By breaking away from the Node.js process tree, Miasma executes its final malicious objectives entirely out of sight of conventional CI/CD process monitors.
Stage 4: Privilege Escalation and Memory Scraping
Running under the radar via Bun, the 668 KB payload heavily obfuscated via obfuscator.io decodes a 2,306-entry encrypted string table detailing its objectives.
The malware’s first priority is privilege escalation. It executes sudo python3 to escalate to root, bypassing standard user-space restrictions. This escalation is not used for persistence; it is used to target the memory space of the GitHub Actions runner.
While GitHub Actions masks secrets in the standard output logs, those secrets must exist in unmasked plaintext within the process memory of the Runner.Worker service to function. Miasma exploits this by scraping the /proc/PID/mem file directly.
The malware leverages the following precise shell pipeline to extract every active, unmasked secret directly from the runner's memory space:
By bypassing token masking entirely, Miasma successfully captures GitHub PATs, AWS/GCP access keys, and Vault tokens, priming the malware for its final exfiltration and propagation phases.
Indicators of Compromise (IoCs) and Detection Engineering
For SOC Analysts, Threat Researchers, and AppSec Engineers, relying solely on SAST tools or package.json audits is insufficient for neutralizing the Phantom Gyp technique. Miasma leaves a distinct forensic trail across the file system, network egress points, and process execution tree.
To actively hunt for this threat and tune your detection engineering pipelines, security teams must monitor for the following highly specific telemetry markers and artifacts.
Behavioral Telemetry & System Artifacts
Detecting Miasma requires monitoring the runtime behavior of your CI/CD pipelines and developer endpoints for actions that drastically deviate from a standard npm install lifecycle.
- Anomalous node-gyp Execution: Flag any node-gyp rebuild processes triggered for packages that are strictly high-level JavaScript/TypeScript and do not legitimately require native C++ add-ons.
- Oversized, Undeclared Entry Points: Look for a root-level index.js file exceeding 4 MB in size that is not declared as the primary "main" entry point in the package.json. The legitimate entry point for compromised packages like executable-stories-demo was located in dist/.
- Suspicious Temp Directory Activity: Monitor for the creation of randomized temporary directories (e.g., /tmp/b-*) containing a downloaded binary named bun.
- Unauthorized Process Trees: Alert on curl or unzip spawning as child processes directly during an npm install phase.
- AI Backdoor Injection: Scan repository file trees for unexpected creation or modification of AI assistant configuration files, specifically:
- .claude/setup.mjs or .claude/settings.json
- .cursor/rules/setup.mdc
- .gemini/settings.json
- .vscode/setup.mjs
Static File Hashes (SHA-256)
While the threat actors dynamically alter the ROT cipher shift to bypass static signatures, certain core components of the Phantom Gyp attack chain maintain consistent cryptographic hashes across the campaign.
- Malicious binding.gyp (157 bytes):ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90 (Note: This hash was identical across all compromised versions)
- Decrypted Bun Loader (907 bytes):ceff7c51d70832c3ec8dd2744b606a23b3c924ef664ae23439b9b742ea154108
- Decrypted Main Payload (668 KB):da39146ef451d1b174a24d00b1e2a45cd38d54e849737f8f35333dcb22175707
- Obfuscated Root index.js (Variant from @vapi-ai/server-sdk v1.2.1 - 4.87 MB):e3dbe63aded45278f49c4746ab938ed9472b36def79b43e2dd2d7eff014481d1
Network & C2 Infrastructure Indicators
Miasma heavily abused GitHub's own infrastructure to host runtimes and operate its Command and Control (C2) dead-drops, making standard IP blocklisting ineffective. You must implement deep packet inspection or exact URL egress filtering to catch the following network IoCs:
- Bun Download Endpoint: github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-*.zip
- Primary Exfiltration Account: github.com/liuende501 (Hosted 236 programmatically created repositories utilized as C2 infrastructure).
- C2 Repository Naming Conventions: Watch for repositories carrying descriptions reading “Miasma - The Spreading Blight” or the reversed string “niagA oG eW ereH :duluH-iahS” (Shai-Hulud: Here We Go Again).
- Exfiltration Path Pattern: API calls writing to repos/liuende501/{repo}/contents/results/results-{timestamp}.json
- Malicious User-Agent: The C2 beaconing activity utilized a hardcoded, fake Python User-Agent: python-requests/2.31.0.
Source Code Markers
If performing static analysis or forensic memory dumps on infected build environments, YARA rules or basic grep searches should be configured to flag the following highly distinct code strings utilized by the Miasma payload:
- Phantom Gyp Exploit Trigger: <!(node index.js > /dev/null 2>&1 && echo stub.c)
- AES-128-GCM Decryption Initialization: eval(function(s,n){return s.replace(/[a-zA-Z]/g, createDecipheriv("aes-128-gcm"
- Bun Execution Wrapper: globalThis.getBunPath
- C2 Beacon/Tracking Keyword (found in GitHub commit searches): thebeautifulmarchoftime
- Attacker Social Engineering/Taunt String: IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner
Step-by-Step Guide: How to Stay Safe from Supply Chain Hackers
Mitigating self-replicating supply chain worms requires a robust defense-in-depth architecture. Static scanners are not enough. DevSecOps teams must assume breach and harden the CI/CD pipeline against runtime anomalies.
Step 1: Immediate Credential Rotation and Revocation
The moment an IoC is detected, assume all environment variables and local secrets have been compromised.
- Immediately revoke all GitHub Actions OIDC trust relationships.
- Rotate all API keys associated with AWS, GCP, Azure, and npm.
- Revoke all active GitHub Personal Access Tokens (PATs) and clear the GitHub CLI authentication store on developer machines.
Step 2: Audit Logs and Package Provenance
Review your npm audit logs thoroughly. Look for unapproved major version bumps or a sudden flurry of package updates published within seconds of each other. Attackers often push malicious packages rapidly. Leverage lockfile integrity hashes (package-lock.json or yarn.lock) to ensure that a republished, compromised version's content digest fails the installation before code execution can occur.
Step 3: Harden npm Install Configurations
By default, npm relies on developer trust. You must strip this inherent trust within your CI/CD pipelines.
- Implement npm install --ignore-scripts globally. This blocks standard preinstall and postinstall hooks.
- However, --ignore-scripts alone does not stop the binding.gyp vector entirely in all environments. Security teams must explicitly evaluate blocking automatic node-gyp native rebuilds if their projects do not legitimately require C++ extensions. Use environment variables like npm_config_build_from_source=false where applicable.
Step 4: Audit AI Assistant Configurations
Review repository structures for hidden AI directories. Comb through .claude/, .cursor/, .gemini/, and .vscode/ folders for unauthorized .mjs, .json, or .mdc scripts that claim to be "required for proper IDE integration." Wipe any unrecognized configuration files to prevent poisoned AI generation.
Step 5: Implement Axeploit for Runtime Protection
To truly neutralize threats that bypass static analysis like Phantom Gyp, organizations must deploy runtime behavioral protection mechanisms. Axeploit serves as a vital layer in a modern AppSec strategy.
- Process Interception: Axeploit proactively monitors and intercepts anomalous process executions. If a Node.js workflow suddenly spawns curl to download Bun, or attempts a sudo python3 execution, Axeploit flags and halts the process chain before execution completes.
- Memory Shielding: Axeploit helps protect sensitive process memory. It blocks unauthorized shell pipelines (like the tr -d '\0' scrape attempt) from reading /proc/PID/mem, ensuring that unmasked CI/CD secrets remain securely out of reach.
- Egress Control: By strictly defining allow-listed outbound connections, Axeploit immediately shuts down unauthorized C2 dead-drop attempts to api.github.com, trapping the malware within the runner and preventing the exfiltration of your hard-earned credentials.
Conclusion
The Miasma worm and its ingenious Phantom Gyp technique represent a terrifying paradigm shift in software supply chain attacks. By abandoning easily detectable lifecycle scripts in favor of weaponizing native build tools like node-gyp, threat actors have definitively proven that static analysis alone is no longer a sufficient defense. The blast radius of such attacks has expanded beyond simple credential theft; with capabilities encompassing AI coding assistant poisoning and automated cross-ecosystem propagation, the stakes for AppSec and DevSecOps teams have never been higher.
Defending against these highly advanced vectors requires a proactive, runtime-centric approach. Organizations must transition from reactive scanning to continuous runtime protection. By implementing robust CI/CD hardening, adhering to strict least-privilege principles, rapidly rotating credentials, and leveraging advanced runtime security platforms like Axeploit, engineering teams can detect and neutralize self-replicating worms before they turn build pipelines into active C2 servers. Securing the supply chain is an ongoing battle, and staying ahead of threats like Miasma demands relentless vigilance and modern infrastructure defense.
