ChainDrop: Unpacking the npm Supply Chain Attack Infecting 860+ Packages
chaindropnpm supply chain attackgithub securitymini shai-huludkeyv packagemicrosoft threat intelligenceaikido securityslsa provenancecredential theftmalwarecybersecurityopen source security

ChainDrop: Unpacking the npm Supply Chain Attack Infecting 860+ Packages

ChainDrop isn't just another security incident; it's a stark reminder of how quickly a single vulnerability can unravel an entire ecosystem. Microsoft Threat Intelligence identified it as a large-scale npm supply chain attack, a variant of the notorious Mini Shai-Hulud worm, known for its self-propagating nature. This wasn't a slow, creeping threat; it was a rapid, widespread compromise that unfolded in hours.

The initial breach started with a compromised GitHub maintainer account behind the popular `keyv` package, which boasts over 600 million monthly downloads. From that single compromise, the attacker unleashed a self-replicating malware that injected malicious code into more than 440 distinct npm packages in under four hours. After that initial wave, it spread to other maintainers, ultimately compromising over 860 packages with a combined total of more than 2 billion monthly installs, according to Aikido Security.

Crucially, these malicious versions were published with valid SLSA provenance—a digital signature meant to verify a package's origin—signed by GitHub Actions. Credential theft bypassed a key trust mechanism. It means the system *thought* these packages were legitimate, even as they were being weaponized.

A dimly lit server room with blinking LEDs, fog drifting through racks, cool blue ambient light with warm rim accents, representing the hidden complexity of a software supply chain.
Dimly lit server room with blinking LEDs, fog
The intricate layers of the npm supply chain, illustrating the hidden attack surface exploited by ChainDrop's rapid propagation.
Server room illustrating the npm supply chain attack.

The Incident: ChainDrop's Rapid npm Supply Chain Attack

The Mechanism: How the Credential Worm Operated

This Mini Shai-Hulud variant is a self-propagating credential-stealing worm, built on the open-source Mini Shai-Hulud repository published by TeamPCP in May, but enhanced with new functionality specifically designed for npm supply chain attacks. The attack chain unfolded as follows:

  1. Initial Access: Initial access was gained via compromised GitHub maintainer credentials, aligning with MITRE ATT&CK T1588.006 (Obtain Capabilities: Compromised Accounts). While the acquisition method is unconfirmed, it provided control over the keyv repository and its npm publishing rights.

  2. Malware Injection: Once inside, the attacker injected a large, heavily obfuscated JavaScript payload—the Mini Shai-Hulud variant—leveraging Bun, a new JavaScript runtime, for its execution.

  3. Execution: The malicious code executed automatically via an npm preinstall lifecycle hook, a script that runs *before* a package is fully installed, running before package installation completed on developer workstations and CI/CD environments. This leverages **MITRE ATT&CK T1059.004 (Command and Scripting Interpreter: JavaScript)** for execution within the supply chain context, specifically **T1195.002 (Supply Chain Compromise: Compromise Software Dependencies and Development Tools)**.

  4. Credential Discovery: The worm initiated credential discovery, collecting npm, GitHub, AWS, CI, AI configuration, and cryptocurrency wallet credentials. It extracted these from local files, environment variables, command-line tools, and GitHub Actions runner memory, a process consistent with **MITRE ATT&CK T1552 (Unsecured Credentials)**, specifically targeting files (**T1552.001**) and environment variables.

  5. Credential Validation & Enumeration: Beyond collection, the worm validated credentials, authenticating to npm, GitHub, AWS, Kubernetes, and HashiCorp Vault. It then enumerated packages, repositories, workflow secrets, cloud parameters, and secret-store values, assessing scopes and writable repositories.

  6. Exfiltration: All collected data was serialized as JSON, gzip-compressed, and then encrypted using strong AES-256-GCM encryption, with the AES key itself protected by the attacker's RSA public key. The primary exfiltration channel is an attacker-controlled dynamic HTTPS endpoint (like hxxps[:]//npm-cache[.]com:443/router). Earlier candidate C2 domains identified during analysis included pypi-get[.]com and js-mirror[.]com. If that fails, it has fallbacks: creating public GitHub repos to commit encrypted results, or leveraging an attacker-controlled domain whose address could be updated via an on-chain contract. This primary channel aligns with **MITRE ATT&CK T1071.001 (Application Layer Protocol: Web Protocols)**.

  7. Propagation (The Worm Part): The propagation mechanism is particularly effective in this npm supply chain attack. Given an npm publishing token with package-write permission and 2FA-bypass capability, the worm enters replication mode. It enumerates other packages accessible to the compromised identity, downloads their latest tarballs, injects its malware and setup loader, adds a preinstall hook, increments the patch version, and republishes the modified packages. This process occurs without corresponding source-code commits or pull requests, making detection challenging in standard code reviews, a clear example of **MITRE ATT&CK T1195.002 (Supply Chain Compromise: Compromise Software Dependencies and Development Tools)** in action.

  8. Persistence: For persistence, stolen GitHub credentials are used to inject malware and setup files into eligible repository branches. It targets Claude and Visual Studio Code configuration paths (.claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and .vscode/setup.mjs) to establish a secondary infection route, ensuring payload restart capability, a method of **MITRE ATT&CK T1547.001 (Boot or Logon Autostart Execution)** through modification of application configuration.

The payload even has preflight checks, exiting on Russian-language systems and avoiding duplicate instances. On developer workstations, it detaches to continue after installation. In CI/CD environments, it stays active to access workflow secrets, runner credentials, and OpenID Connect (OIDC) publishing permissions, which grant access to external services.

The Impact: Erosion of Trust and Cloud Vulnerability from npm Supply Chain Attacks

ChainDrop's scale is significant: over 860 packages compromised, affecting more than 2 billion monthly installs. This makes it one of the most impactful npm supply chain attacks to date. Wiz researchers found that the compromised packages, including keyv, flat-cache, and file-entry-cache, are present in over 46% of all cloud environments. For context, the Shai-Hulud 2.0 campaign's most prevalent packages appeared in approximately 28% of environments. ChainDrop thus presents a considerably wider potential impact.

The practical implications are stark: any organization using these compromised packages, whether directly or indirectly, risked having their npm, GitHub, AWS, CI/CD, AI, and even cryptocurrency credentials stolen. A single developer's compromised account can provide keys to entire cloud environments and development pipelines.

While direct attribution to TeamPCP for this specific attack remains unconfirmed, the malware's evolution aligns with their known tactics. TeamPCP has a track record, having compromised over 1,000 software packages in less than four months earlier this year. This suggests a persistent, evolving threat actor.

A close-up of a developer's hands typing on a keyboard, with lines of code reflected in their glasses, conveying the vulnerability of individual workstations and the widespread impact on the developer ecosystem.
Close-up of a developer's hands typing on
A developer's workstation, a critical node in the supply chain, illustrating how the worm propagated from individual systems to broader cloud environments.
Developer typing on a keyboard.

The Response: Immediate Actions and Systemic Improvements

In response, Microsoft, alongside security firms such as Aikido Security and Wiz, has been actively analyzing the attack and offering guidance. Immediate mitigation requires a multi-faceted approach.

Organizations must immediately update npm CLI to v12 and enable the `npm CLI min-release-age` feature. This prevents new package versions from being published too quickly after a previous one, creating a crucial window for detection and intervention. A thorough scrutiny of dependency trees, lockfiles, artifact repositories, and CI caches is essential to identify and purge compromised versions, including transitive references. Pinning known-good package versions acts as a crucial preventative measure against accidental re-infection.

Furthermore, clearing npm and yarn caches on all affected developer endpoints and build hosts is a non-negotiable first step. Following this, a complete rotation of all credentials and secrets from a clean host is imperative if any build system or workstation imported a compromised version. Finally, ensure all endpoint protection, container security, and extended detection and response (XDR) investigation workflows are fully enabled and configured.

Review release hardening, token scopes, workflow approvals, protected environments, release provenance, and anomaly detection around automated package publication for CI/CD pipeline abuse. After remediation, validate recovery by rebuilding affected projects from a known-good dependency baseline, confirming the absence of compromised hashes (e.g., for `setup.mjs`) and reviewing endpoint telemetry for NodeJS directory artifacts (e.g., `Math_Symbol.js`, `Math_init.js`, `math_.js`) or suspicious node child processes. Rebuilding shared base images or golden build runners is also a critical step.

These are crucial reactive measures. The broader community's frustration highlights the recurring nature of these attacks and the perception that fundamental issues persist. The fact that valid SLSA provenance was signed by GitHub Actions for malicious packages significantly erodes trust. Provenance was intended as a key mechanism for supply chain integrity verification. Its failure in this instance prompts serious questions about the efficacy of existing defenses.

Moving beyond reactive patching requires systemic changes. Mandatory code signing, not just for packages but for maintainers, would add a verification layer more resistant to credential theft. Phishing-resistant MFA, such as FIDO2/U2F (hardware security keys), should become a standard requirement, as SMS or app-based MFA remains susceptible to phishing. Platforms also need credential change policies that prevent new package versions from being published for a defined period after a maintainer's credentials are changed or reset, creating a crucial window for detection. Finally, npm and GitHub require enhanced anomaly detection for publishing behavior. Rapid, uncharacteristic updates, particularly from accounts with prior inactivity, should trigger immediate flags and holds.

The ChainDrop npm supply chain attack clarifies that relying solely on one security control, even one as robust as SLSA provenance, is inadequate when initial credential compromise is successful. A layered security approach is critical, extending beyond package integrity to encompass maintainer and platform controls. Developer skepticism is warranted; platforms must actively rebuild that trust through fundamental, systemic improvements to prevent future npm supply chain attacks.

Daniel Marsh
Daniel Marsh
Former SOC analyst turned security writer. Methodical and evidence-driven, breaks down breaches and vulnerabilities with clarity, not drama.