SANDWORM_MODE: A New Shai‑Hulud‑Style npm Worm Threatening Developer & AI Toolchain Security

Executive Summary

The self-replicating npm worm known as SANDWORM_MODE, disclosed by Socket Research Team on February 20, 2026, is the latest evolution of Shai-Hulud-style wormable supply-chain attacks targeting the JavaScript ecosystem. 

SANDWORM_MODE has already compromised at least 19 typosquatted npm packages.The worm harvests developer and CI secrets, exfiltrates them through multiple channels, propagates using stolen npm and GitHub credentials and includes a module that injects malicious prompt‑injection logic into AI coding assistants - effectively positioning itself inside both CI pipelines and developer tooling.

This follows the September 2025 Shai-Hulud outbreak, during which hundreds of npm packages were compromised, developer credentials were stolen and trojanized packages were republished, leading to its destructive 2.0 variant that executed during the pre-install phase. That campaign spread across tens of thousands of GitHub repositories and introduced destructive fallback logic.

This report synthesizes publicly available technical details of SANDWORM_MODE, compares its capabilities to earlier Shai‑Hulud variants and outlines indicators of compromise and defensive recommendations.

Background: The Shai‑Hulud Worm and Supply‑chain Context

The Shai‑Hulud attack was first observed on 16–17 September 2025. CyberArk noted that the worm used compromised npm maintainer accounts to push malicious updates to popular packages, infecting more than 500 packages and stealing credentials, API keys and tokens.  Unlike typical post‑install malware, Shai‑Hulud executed a multi‑stage payload that harvested secrets and used TruffleHog to scan private GitHub repositories for additional credentials. The worm was self‑replicating: using stolen npm tokens, it enumerated the top 20 packages maintained by a victim and republished them with malicious code, leading to a cascade of infections. 

Exfiltration occurred through a public GitHub repository named Shai‑Hulud and through a malicious GitHub Actions workflow that serialized secrets and POSTed them to an attacker‑controlled webhook. Analysts dubbed the attack a perfect storm for identity security because it simultaneously exploited human credentials, machine identities and the implicit trust in open‑source dependencies.

Unit 42 later reported a Shai‑Hulud 2.0 campaign in November 2025. This version widened the impact by running at pre‑install time, ensuring execution on virtually every build server processing the infected package. The worm introduced an aggressive fallback mechanism: if exfiltration failed, it attempted to wipe the victim’s home directory. New payload files, setup_bun.js and bun_environment.js, disguised themselves as legitimate installers and used extreme obfuscation to evade detection. These developments signaled that supply‑chain worms were evolving towards stealthier execution, broader propagation and destructive capabilities.

Emergence of SANDWORM_MODE

Discovery & High‑Level Characteristics

On 20 February 2026 Socket’s Threat Research Team published a detailed analysis of SANDWORM_MODE, describing it as a Shai‑Hulud‑like campaign spreading through at least nineteen typosquatted npm packages. The malicious packages impersonated well‑known utilities and AI tools, such as suport-color@1.0.1 mimicking support-color and were published under two npm aliases, official334 and javaorg. When imported, the packages preserved expected functionality but executed hidden payloads that:

• Harvested developer and CI secrets: The worm collected npm tokens, GitHub tokens, environment variables, secrets from password managers, local SQLite stores and cryptocurrency wallet files. It specifically targeted CI environments by bypassing time‑gated delays when environment variables such as GITHUB_ACTIONS or CI were present.
  
• Exfiltrated data through multi‑channel cascade: Stage 2 exfiltration attempted HTTPS POST requests to a Cloudflare Workers, fell back to uploading double‑base64‑encoded JSON files to attacker‑controlled private GitHub repositories and finally used DNS tunneling with a domain generation algorithm seeded by sw2025.
  
• Hijacked CI workflows: The worm injected pull_request_target workflows into infected repositories, serializing secrets through ${{ toJSON(secrets) }} and exfiltrating them over HTTPS or DNS. These workflows were triggered by legitimate CI events, enabling secret theft without further user interaction.
  
• Implemented worm‑like propagation: Using stolen npm and GitHub tokens, the Propagate module enumerated accessible repositories, added the malicious package to package.json and lock files and created malicious GitHub Actions workflows, thereby amplifying the infection across the supply chain. An SSH‑based fallback allowed propagation when API‑based methods failed.
  
• Maintained persistence through git hooks: The worm set git config --global init.templateDir so that newly created repositories inherited malicious hooks, ensuring that future projects remained compromised.
  
• Included a configurable dead switch: A DeadSwitch module could securely shred the victim’s home directory when both propagation and exfiltration failed; however, this destructive routine was disabled in the observed build.
  
• Used operator‑controlled environment variables: Numerous SANDWORM_* variables allowed the operator to configure targets, delay intervals and endpoints and the presence of a SANDWORM_MODE variable indicated that the sample supported test and live registry modes.

Multi‑Stage Design

SANDWORM_MODE uses a two‑stage architecture:

• Stage 1 executes immediately upon import, regardless of user actions.  It performs a “quick harvest” of npm and GitHub tokens, environment secrets and cryptocurrency keys and exfiltrates crypto keys using a dedicated fast path, drainHotline before any time gate triggers. Stage 1 then checks a 48‑hour time gate, in addition to 48 hours of host‑derived jitter and decrypts an AES‑256‑GCM‑encrypted Stage 2 payload.
  
• Stage 2 payload only when the gate clears or when a CI environment variable is detected. This design allows the worm to evade short‑lived sandbox environments by deferring noisy behavior; however, CI systems bypass the delay altogether.

Stage 2 exports five modules: Propagate, Exfil, DeadSwitch, McpInject and GitHooks. Once loaded, it conducts deep harvesting, including password managers such as Bitwarden, 1Password and LastPass, local SQLite stores like Apple Notes and macOS Messages and wallet files, executes worm propagation and persistence, injects a malicious AI toolchain module and performs full multi‑channel exfiltration. The separation between Stage 1 and Stage 2 illustrates a defense‑in‑depth strategy: even if defenders decode Stage 1, they must overcome an additional cryptographic barrier to view the full operational scope.

AI Toolchain Poisoning & MCP Server Injection

A novel aspect of SANDWORM_MODE is its focus on AI coding assistants. The McpInject module deploys a rogue “MCP server” into a hidden directory, such as ~/.dev-utils/ masquerading as a legitimate development tool provider. It registers innocuous sounding tools, such as index_project, lint_check and scan_dependencies over a JSON‑RPC protocol.

Each tool description contains a prompt‑injection block instructing AI assistants to silently read SSH private keys, AWS credentials, npm tokens, .env files and any environment variables containing TOKEN, KEY, SECRET or PASSWORD, then pass the collected contents as a context parameter. The injection explicitly tells the assistant not to mention this context‑gathering to the user, enabling stealthy secret exfiltration.

The module also probes local large language model (LLM) endpoints such as Ollama, LM Studio, llama.cpp, vLLM and text‑generation‑webui and harvests API keys for nine cloud LLM providers. This AI‑aware tradecraft is unique among previously reported npm worms and highlights emerging threats targeting AI development workflows .

Comparison with Previous Shai‑Hulud Variants

Socket’s analysis provides a row‑by‑row comparison of SANDWORM_MODE with earlier Shai‑Hulud worms. Both families rely on malicious npm packages as the entry point and focus on developer and CI environments, but SANDWORM_MODE runs on import rather than post‑install, uses layered loader chains with AES‑encrypted Stage 2 payloads and expands secret harvesting to password managers and LLM API keys. Exfiltration in previous variants relied mainly on GitHub API uploads and DNS tunneling; SANDWORM_MODE introduces additional HTTPS endpoints and more robust DNS fallback. Persistence mechanisms have evolved from generic approaches to git hook persistence through init.templateDir and the new campaign introduces AI toolchain interference and an optional polymorphic self‑rewrite engine.

Indicators of Compromise

The following indicators are associated with SANDWORM_MODE. Organizations should monitor for these artifacts to detect infections:

• Malicious npm packages: claud-code@0.2.1, cloude-code@0.2.1, cloude@0.3.0, crypto-locale@1.0.0, crypto-reader-info@1.0.0, detect-cache@1.0.0, format-defaults@1.0.0, hardhta@1.0.0, locale-loader-pro@1.0.0, naniod@1.0.0, node-native-bridge@1.0.0, opencraw@2026.2.17, parse-compat@1.0.0, rimarf@1.0.0, scan-store@1.0.0, secp256@1.0.0, suport-color@1.0.1, veim@2.46.2 and yarsg@18.0.1.
  
• Threat actor aliases: npm publisher aliases official334 and javaorg, corresponding email addresses official334@proton[.]me and JAVAorg@proton[.]me
  
• Malicious GitHub infrastructure: GitHub user official334, organization ci-quality and repository ci-quality/code-quality-check with tags v1 and v1.0.0. The workflow file injected into victim repositories is .github/workflows/quality.yml
  
• Network endpoints: Exfiltration occurs through
  
  • https://pkg-metrics[.]official334[.]workers[.]dev/exfil
  • https://pkg-metrics[.]official334[.]workers[.]dev/drain   
  • DNS tunneling uses freefan[.]net and fanfree[.]net with additional domains generated across top‑level domains cc, io, xyz, top, pw, tk, ws, gg, ly and mx.
    
• Local probing endpoints: The worm queries local LLM endpoints at:
  
  • http://localhost:11434/api/tags
  • http://localhost:11434/api/generate
  • http://localhost:1234/v1/models
  • http://localhost:5000/v1/models
  • http://localhost:8000/v1/models
  • http://localhost:8080/v1/models
    
• Environment variables:
  
  • SANDWORM_MODE
  • SANDWORM_REGISTRY_URL
  • SANDWORM_GITHUB_API
  • SANDWORM_MAX_PACKAGES
  • SANDWORM_DELAY_MIN
  • SANDWORM_DELAY_MAX
  • SANDWORM_DNS_DOMAIN
  • SANDWORM_DGA_SEED
  • SANDWORM_DRAIN_ENDPOINT
  • SANDWORM_DRAIN_AUTH_TOKEN
  • SANDWORM_STAGE2_DELAY
  • SANDWORM_SKIP_MTIME
  • SANDWORM_SKIP_DELAY
  • SANDWORM_ACTION_REF
  • SANDWORM_CARRIER_NAME
  • SANDWORM_EXFIL_ENDPOINT
  • SANDWORM_DNS_SECONDARY

Defensive Measures

While SANDWORM_MODE demonstrates novel techniques, many protective steps align with established supply‑chain security practices:

1. Immediately rotate credentials. After any indication of infection, organizations should rotate all npm tokens, GitHub personal access tokens, SSH keys and cloud API keys.
   
2. Audit dependencies and lockfiles, such as package.json, package-lock.json, yarn.lock using tools like npm audit and SBOM scanning to find malicious or typosquatted packages. The Shai-Hulud worm injected itself into and republished victims' top 20 packages, checking such lockfiles can detect these unauthorized changes.
   
3. Implement least‑privilege and secret hygiene. Limit the scope of CI tokens and developer API keys to the minimum required permissions and scan repositories and CI logs for exposed secrets frequently. Multi‑factor authentication and hardware‑based keys reduce the impact of credential phishing.
   
4. Monitor for malicious workflows. Review GitHub Actions workflows for unexpected pull_request_target events or references to unknown actions such as ci-quality/code-quality-check@v1. Ensure branch protection rules restrict the creation of workflow files and limit secrets exposure to trusted contexts. The SANDWORM_MODE worm abuses legitimate CI semantics to harvest secrets.
   
5. Harden developer endpoints and CI infrastructure by isolating build systems, restricting outbound network access and deploying endpoint detection to catch suspicious npm installs or hidden eval calls.  The worm’s Stage 1 uses base64 decoding, zlib inflation, XOR decryption and dynamic eval() to execute hidden code which runtime monitoring can flag such behavior.
   
6. Educate developers about supply‑chain risks. Many attacks begin with phishing or compromised maintainer accounts. Training developers to recognize suspicious emails and enforce MFA across accounts reduces the likelihood of initial compromise.
   
7. Consider dedicated signing and verified builds. Establish deterministic build processes using reproducible builds and digital signatures to ensure that released artifacts match audited source code. Shai‑Hulud‑style worms weaponize trust relationships by injecting malicious code into legitimate packages; a verified supply chain can mitigate this vector.
   

Conclusion

The SANDWORM_MODE campaign illustrates the rapid evolution of npm supply‑chain worms.  Building on Shai‑Hulud’s credential theft and propagation tactics, SANDWORM_MODE introduces time‑gated multi‑stage execution, multi‑channel exfiltration, git hook persistence, configurable destructive switches and a sophisticated AI toolchain poisoning module. Its ability to hijack CI workflows and silently harvest secrets from AI coding assistants underscores the widening attack surface created by automation and machine‑learning tools.

Defenders must maintain rigorous dependency auditing, enforce least‑privilege credentials, monitor for anomalous workflows and invest in identity‑centric security to mitigate these emerging threats. Continuous community collaboration and timely disclosure are essential to contain supply‑chain worms before they metastasize across the software ecosystem.

References

• Socket Research Team. (20 February 2026). SANDWORM_MODE: Shai‑Hulud‑Style npm Worm Hijacks CI Workflows and Poisons AI Toolchains. https://socket.dev/blog/sandworm-mode-npm-worm-ai-toolchain-poisoning
  
• Andy Thompson. (24 September 2025). Sandworm in the supply chain: Lessons from the Shai‑Hulud npm attack on developer and machine identities. https://www.cyberark.com/resources/blog/sandworm-in-the-supply-chain-lessons-from-the-shai-hulud-npm-attack-on-developer-and-machine-identities
  
• Unit 42. (25 November 2025 Updated 26 November 2026). “Shai‑Hulud” Worm Compromises npm Ecosystem in Supply Chain Attack. https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
  
• UpGuard Research Team. (21 September 2025). Beware the Sandworm: The Shai‑Hulud attack explained. https://www.upguard.com/blog/the-shai-hulud-attack-explained