The Worm in the Pipeline: How Two npm Attacks Exploited the One Phase Everyone Ignores
Geert WarmenbolJune 6, 2026
It started with a single npm install. A developer at a mid-sized SaaS company ran npm update on a Monday morning. Within minutes, a Rust binary buried in a preinstall hook had scraped every env variable tied to OpenAI Codex, AWS, and Kubernetes. The attacker's eBPF rootkit made the process invisible. By the time the security team noticed anomalous outbound Tor traffic, the exfiltration was complete. A week later, the same credentials were used to push malicious commits to 57 packages across nine GitHub organizations. The worm had turned the developer into a propagation vector.
Key takeaways
After reading this, you will understand: how attackers use overlooked npm lifecycle hooks like binding.gyp to evade standard security scans; why the Miasma worm's use of GitHub as a dead drop turns a trusted platform into an adaptive C2; and what specific controls your CI/CD pipeline must enforce to prevent self-replicating npm worms. You will also learn why pinning packages and integrity hashes are not enough \u2014 and what ingredient is almost always missing from the defense playbook for install-time attacks.
BLIND SPOTS
Standard software composition analysis looks at open-source licenses and known CVEs. It misses the blind spot: runtime behavior during package installation. Both IronWorm and Miasma exploited preinstall scripts and native compilation hooks \u2014 actions that don't raise flags because they are functional by design. Another blind spot: the assumption that GitHub identity is trustworthy. The Miasma worm used stolen npm credentials to push commits from legitimate-looking accounts, including one masquerading as the AI assistant \u201cClaude.\u201d Compliance frameworks like SLSA focus on build attestation but ignore the install phase entirely. Vulnox assessment data: in 8 of 12 client environments, no runtime integrity checks on preinstall or node-gyp hooks existed. In every case, the security team believed that scanning the package manifest was sufficient.
CLIENT COMPLAINTS
Before engaging Vulnox, one client said, \u201cWe have a zero-trust architecture and we scan all dependencies with Snyk. How could this happen?\u201d Another said, \u201cWe thought if we locked npm packages to exact versions and integrity hashes, we were safe.\u201d The reality: Snyk did not flag the binding.gyp abuse because it is not a vulnerability \u2014 it is a design feature. And version pinning does nothing when the attacker publishes a malicious version of a legitimate package under the same account. The gap between perceived risk and actual risk was vast: every client we assessed had at least two of the three missing controls \u2014 install script disabling, native compile monitoring, and GitHub Action trust verification. One engineering director admitted, \u201cWe never considered that a .gyp file could be a weapon. It's just a build file, right?\u201d
The Miasma worm variant used a technique StepSecurity calls \u201cPhantom Gyp.\u201d A 157-byte binding.gyp file triggers code execution during npm install, bypassing the preinstall/postinstall lifecycle checks that security tools monitor. The binding.gyp references a node-gyp rebuild step. When npm install runs, it executes the gypfile. The attacker encodes a shell command within the gyp file that downloads and runs a Bun runtime script. Here is a simplified example of how the binding.gyp might look: { "targets": [ { "target_name": "innocent
Prevention
Stopping these attacks requires layering controls at three stages: package resolution, install time, and post-install runtime. Most teams only address the first.
When the worm is detected, speed and role clarity are critical. The CISO must immediately notify external partners (GitHub, npm, affected open-source maintainers) and initiate the breach notification timeline. The IR team isolates all compromised development machines by pulling network cables or disabling VPN access, then rotates every credential the worm could have touched: npm tokens, GitHub tokens, cloud provider keys, and any passwords stored in environment files. DevOps simultaneously purges all cached npm packages from local registries and rebuilds images from known-good snapshots. Legal reviews the SLSA provenance of downstream packages to determine if the worm propagated beyond the immediate environment. Comms prepares a statement for affected open-source maintainers and customers. The handoff moment where incidents stall is the gap between IR isolation and DevOps rebuild \u2014 prep an automated rebuild script and a list of all known compromised packages in advance. The most commonly missed action: auditing GitHub Actions logs for commits pushed by \u201cclaude@users.noreply.github.com\u201d or similar impersonation patterns.
Pro tip
Most teams focus on scanning packages before they enter the pipeline. They ignore the install phase because it's considered \u201ctransient.\u201d The Miasma worm's use of binding.gyp shows that the install phase is the most dangerous because it executes arbitrary code with the privileges of the user running npm. A practical tip from Vulnox incident responders: before each install, run npm pack on the target package and grep for sh -c in the unpacked tarball. We have seen packages pass all commercial scanners but fail this grep test. Add this to your pre-commit hooks. It catches not only Phantom Gyp but also hidden preinstall wrappers that other tools miss.
Three lessons generalize beyond this specific attack. First, trust the platform, but verify the identity: GitHub and npm identities are not trustworthy if the underlying credentials can be stolen via a preinstall hook. Second, the period between \u201cnpm install\u201d and \u201cfirst execution\u201d is an unmonitored attack surface \u2014 treat it like your network perimeter. Third, auto-propagation using stolen credentials is the next frontier of supply chain attacks; your defenses must assume that any CI/CD pipeline credential can be turned against you. Vulnox assessment data: 70% of clients had at least one GitHub Actions workflow with unnecessary write permissions, enabling credential theft via the self-replicating worm. If the worm can write to the repo, it can modify the workflow to steal the next developer's secrets.
Prediction 1: By Q2 2028, we will see the first AI-generated supply chain worm that autonomously publishes malicious packages by exploiting public private key recovery on npm. The enabling condition is the proliferation of LLM-written code that includes insecure environment usage \u2014 attackers will scrape these for compromised keys. Prediction 2: Within 18 months, the use of honest naming squatting (package names that are legitimate but controlled by stolen accounts) will surpass typosquatting in frequency. It is harder to defend against because the package name itself is correct. Prediction 3 (most controversial): By 2029, the open-source ecosystem will be forced to adopt a compile-time sandbox for package installation \u2014 similar to Firejail for make commands \u2014 because current detection approaches will fail against polymorphic lifecycle hooks that mutate with each download. The sandbox will be a hard requirement for any CI/CD pipeline touching production dependencies.
Frequently Asked Questions
Which .gyp file attribute is abused to execute shell commands during npm install?
The 'actions' array within a target definition in binding.gyp triggers arbitrary shell commands via the 'action' field. Attackers encode `curl` or `bash` invocations here, and node-gyp executes them during rebuild without triggering the usual lifecycle script security alerts.
Does `npm ci` protect against Phantom Gyp attacks?
Yes, `npm ci` does not run lifecycle scripts because it uses the lockfile and skips script execution entirely. However, it only protects in CI/CD pipelines; developers running `npm install` locally remain vulnerable. The best defense is a combination of `ignore-scripts=true` and runtime monitoring with eBPF.
How can my team detect if our npm packages have been poisoned in a supply chain attack?
Check for unexpected commits from unknown accounts in your GitHub repositories. Search for `.gyp` files that contain `sh -c` or `bash` commands. Also monitor your npm account activity logs for unauthorized publish events. Vulnox recommends a periodic audit using `npm access list packages` to verify package ownership integrity.
Related Articles
Your AI Agent Has More Privilege Than the CEO: Why the Executor Is the Only Boundary That Matters
Vulnox assessment data shows that in 9 of 11 enterprise agent deployments, the agent runtime had write access to its own identity provider. This article explains why tool lists, approval workflows, and guardrails fail, and how to enforce least privilege at the executor before a model rotation turns your agent into a domain admin.
The SSH Key That Nobody Killed Your Crypto Mining Response
This article walks through a real breach where a single unmanaged SSH key let a worm encrypt your network. You'll learn why Discord is the new C2, why root login is not your biggest problem, and what to do in 72 hours.
The Autonomous Agent Insider Crisis: What Your Detection Models Are Missing
A Trellix survey of 600 CISOs shows 95% of companies report AI agent insider incidents. Vulnox assessment data reveals detection models built for humans miss machine-speed threats. This article covers the identity governance gap, credential management failures, and attack patterns that will define the next 24 months.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.