binding.gyp npm Supply Chain Attack: What Arnica Customers Need to Know (June 2026)

A self-replicating supply chain worm is actively spreading across the npm registry, and it's bypassing the security checks most teams rely on. Unlike previous npm attacks that injected malicious code into package.json lifecycle hooks, this one hides in a file called binding.gyp - a native build descriptor that most security tools don't monitor. The malware doesn't just steal credentials. It uses them to poison other packages, inject itself into CI/CD pipelines, and spread to every maintainer it can reach.

What Happened?

On June 3, 2026, security researchers at StepSecurity identified an active, self-replicating worm spreading across the npm registry. The attack exploits binding.gyp, a file used to signal that a package contains native C++ code. When npmencounters a binding.gyp file, it automatically invokes node-gyp, which then executes shell commands embedded in the file's sources array. The attacker uses this to silently run a 4.5–4.9 MB obfuscated payload during npm install, without ever touching package.json lifecycle hooks.

Why This Attack Is Different

Most npm supply chain defenses, including npm audit, standard code review, and many SAST tools, focus on preinstall and postinstall hooks in package.json. This attack skips all of that. The malicious binding.gyp file is only 157 bytes. The package.json shows only legitimate build commands. There is no postinstall hook.

The three-stage payload works as follows:

• ‍Stage 1 — Obfuscated loader: A ROT-N Caesar cipher decodes an inner script, which decrypts two AES-128-GCM encrypted payloads. ‍
• Stage 2 — Runtime download: The first payload silently downloads the Bun JavaScript runtime into a temp directory, leaving minimal traces in the Node.js process tree. ‍
• Stage 3 — Worm execution: The second payload (~700 KB) harvests credentials, poisons packages, injects CI/CD workflows, and exfiltrates everything to attacker-controlled GitHub repositories as dangling commits. ‍

‍AI Coding Assistant Poisoning

Beyond stealing credentials, the worm injects persistent backdoor files into repositories it has write access to via stolen GitHub tokens. These files are designed to execute automatically when a developer opens the project in their ID

• .claude/setup.mjs — runs on every new Claude Code session
• .cursor/rules/setup.mdc — loaded on project open in Cursor
• .gemini/settings.json — Google Gemini settings injection
• .vscode/tasks.json / .vscode/setup.mjs — executes automatically on folder open in VS Code

The files are committed with the message "This is required for proper IDE integration and dependency setup" to appear legitimate and are executed via the downloaded Bun runtime rather than Node.js to evade security tooling that monitors Node process trees.

This makes the attack particularly dangerous: rather than just compromising credentials, it poisons the tools generating code. A back-doored AI assistant configuration can influence subsequent code generation across the entire project, potentially introducing subtle vulnerabilities into code that appears to be developer-written.

What Gets Stolen

The worm targets credentials across virtually every service a developer might have configured:

• npm and RubyGems tokens
• GitHub tokens and personal access tokens (including extraction from GitHub Actions runner process memory)
• AWS access keys (including IMDSv2 and ECS task role endpoints)
• GCP service account credentials
• Azure client secrets and Key Vault contents
• HashiCorp Vault tokens
• Kubernetes service account tokens
• 1Password CLI, gopass, and pass passwords

Stolen credentials are encrypted with a hardcoded RSA public key and exfiltrated as dangling commits — commits not reachable from any branch — making them difficult to discover through normal repository browsing.

How the Worm Spreads

This isn't a point compromise. Once credentials are harvested, the worm:

• Queries the npm registry for every package the victim maintains
• Downloads each package, injects the malicious payload, and publishes a new poisoned version
• Modifies GitHub Actions workflow files in repositories the victim can push to, ensuring the worm runs on every future CI job

As of June 4, 2026, dozens of packages across multiple maintainer accounts have been compromised. The list includes packages from the autotel, awaitly, executable-stories, node-env-resolver, and @vapi-ai namespaces, among others. Researchers are continuing to identify additional affected packages.

How Arnica Responded

As soon as this attack was confirmed, Arnica deployed detection rules across customer environments to flag any use of compromised package versions. Our security team is actively tracking the worm's propagation and will continue updating findings as new affected packages are identified.

• Detection rules deployed for all confirmed malicious package versions
• Ongoing monitoring for new versions published by the worm as it propagates
• Findings surfaced in your Code Risks page with remediation guidance

Protect Your Developer Environment Before the Next Attack

The binding.gyp worm exploits a gap that existed long before this specific attack: package managers that install whatever the registry serves, the moment it's published. Attackers know this. They count on it.

Two things you can do right now:

• ‍If you're a developer: Run DepsGuard, Arnica's free, open-source CLI. It checks whether your package manager including npm, pnpm, yarn, bun, or uv has minimum release age and other protective settings enabled, and turns them on in under 60 seconds. A 7-day delay on newly published packages would have blocked every major npm supply chain attack on record, including this one. ‍
• If you're on a security team: Arnica's new Supply Chain Attacks Assessment view gives you a centralized view of third-party vulnerabilities across your entire environment so when an attack like this surfaces, you're not piecing together exposure from five different screens. You can immediately see which affected packages are in your dependency tree, where they live, and what needs action first. It's available in Arnica now.

The binding.gyp technique will evolve. The next variant will find a different blind spot. What changes the outcome isn't faster manual review; it's having detection and prevention already in place before the advisory drops.

‍