Cybersecurity

Microsoft Analysis of the ChainDrop Attack: Self-Propagating Worm Infects More Than 400 npm Packages

Microsoft Threat Intelligence analyzed a widespread attack on the npm supply chain in which a credential-stealing worm was hidden inside more than 400 packages published by different entities. The malware collects developer and CI/CD environment secrets, then uses npm and GitHub tokens to republish malicious versions and open additional propagation paths.

2026-08-04
6 min read
8 views
فريق تحرير certi.news
Microsoft Analysis of the ChainDrop Attack: Self-Propagating Worm Infects More Than 400 npm Packages

Microsoft Threat Intelligence disclosed details of a widespread attack on the npm supply chain that affected more than 400 packages associated with apparently unrelated publishers, including packages within enterprise software ecosystems such as keyv, flat-cache, and cache-manager. The malicious releases included a version of the Mini Shai-Hulud worm, a highly obfuscated JavaScript payload built on Bun and designed to steal credentials and spread automatically by republishing malicious updates.

The attack is particularly significant because of how it operates: the malware does not merely steal tokens from a developer's device or a build environment; it also uses those tokens to access npm, GitHub, Amazon Web Services, Kubernetes, and HashiCorp Vault, then examines the resources and secrets permitted by the stolen identities. According to Microsoft's analysis published on August 4, 2026, any workstation or build agent that imported an affected package with npm lifecycle scripts enabled should be treated as potentially compromised.

Early Execution Within Development Environments

The affected releases typically added a preinstall script that runs a file named setup.mjs before package installation is complete. The file launches a large, obfuscated Bun bundle, allowing the payload to execute on developer devices and build nodes before application testing begins or some traditional security checks reach this stage.

The worm first examines the environment to determine whether it is running on a developer workstation or within a CI/CD job. On developer devices, it detaches itself so that it can continue running in the background after installation ends, while in CI/CD environments it remains attached to the job to take advantage of workflow secrets, agent credentials, and deployment permissions through OpenID Connect. It also checks that another copy is not running and stops on systems using the Russian language, according to Microsoft's observations.

Stealing Credentials and Turning Them Into Propagation

The payload begins by collecting locally available credential files, environment variables, command history, SSH keys, and cloud tools, in addition to data from GitHub Actions runner memory. Among other things, it attempts to obtain a GitHub CLI token. It then uses the extracted credentials to call the APIs of npm, GitHub, AWS, Kubernetes, and HashiCorp Vault, verify permissions, and collect additional secrets.

The results are encrypted as compressed JSON using AES-256-GCM, with the AES key encrypted through RSA-OAEP-SHA256, and then sent to an attacker-controlled HTTPS endpoint. GitHub is used as an alternative channel for data exfiltration when the primary channel is unavailable. Microsoft noted that the active infrastructure at the time of analysis resolved to npm-cache[.]com, while earlier candidates included pypi-get[.]com and js-mirror[.]com.

The primary propagation mechanism examines npm tokens to determine whether they permit writing to packages or bypassing multifactor authentication, then downloads the latest tarball for each package available to the compromised identity. The worm copies itself into the archive, adds the setup loader and lifecycle script, increments the patch version, and republishes the package. This explains the appearance of malicious releases that look like ordinary patch updates without a corresponding commit, pull request, or matching release tag in the source repository.

Additional Paths Through GitHub

The payload checks GitHub token scopes, enumerates writable repositories, and searches for repositories in which workflows could expose additional secrets. It also includes a path targeting npm packages published through GitHub Actions as trusted publishers, which may give published releases valid provenance because the publication comes from a legitimate workflow identity.

The worm can also inject configuration files into repository branches, including Claude- and Visual Studio Code-related paths such as .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, and .vscode/setup.mjs. These modifications provide a secondary infection path that can rerun the payload while Claude or Visual Studio Code is being used, even after installation of the original package has ended. Microsoft said that one of the backup GitHub paths also attempts to install a token-monitoring component, with a conditional destructive handler when the monitored token is revoked.

What Does Microsoft Recommend?

Microsoft recommends updating the npm CLI to version 12 and using the min-release-age feature, as well as reviewing dependency trees, lockfiles, artifact repositories, and CI caches for the five affected releases, including indirect references. Known-safe versions should also be pinned, and npm and yarn caches should be cleared on developer devices and build hosts, particularly when the compromised archives have entered a shared CI cache.

If a build system or workstation imported an affected release, credentials and secrets should be rotated from a clean device, because execution from the second stage could expose tokens and affect build integrity. Recommendations also include enabling cloud protection for Microsoft Defender Antivirus, Microsoft Defender for Endpoint measurements, Microsoft Defender for Containers, and the investigation workflow in Microsoft Defender XDR across development and CI assets.

Response should not be limited to scanning devices. Organizations that produce software artifacts should review the hardening of the release process, token scopes, workflow approvals, protected environments, release provenance, and mechanisms for detecting unusual automated publishing, because the incident is consistent with abuse of CI/CD pipelines through GitHub Actions OIDC permissions. After remediation, projects should be rebuilt from a trusted baseline, compromised fingerprints should be confirmed absent from caches and artifact repositories, and telemetry should be reviewed for remnants of Node.js such as Math_Symbol.js and Math_init.js or files with names resembling math_<guid>.js, along with rebuilding base images and standardized build agents.

News source
Microsoft Security Blog
Open original source ↗
ف
Author

فريق تحرير certi.news

In the same category

You may also like

View all news