A new npm supply-chain attack has compromised hundreds of JavaScript packages and turned stolen developer credentials into a mechanism for spreading the malware to additional projects. Researchers tracking the campaign have identified 444 unique npm packages and 2,212 compromised versions in one August 4 investigation snapshot, while separate researchers recorded different totals as the campaign evolved.
The incident, dubbed ChainDrop, has been analyzed independently by security researchers including StepSecurity, Microsoft and Palo Alto Networks.
Their investigations show a campaign designed not only to execute malicious code when affected packages are installed, but also to collect credentials from developer systems and continuous integration and continuous delivery environments, use those credentials to access additional packages and repositories, and continue propagating.
The scale figures require careful attribution. StepSecurity’s detailed August 4 forensic analysis counted 444 unique packages and 2,212 compromised versions during a period of roughly 09:40 to 13:20 UTC.
Other investigations produced different counts based on later or different snapshots, so the figures should not be combined into a single campaign total. StepSecurity’s technical analysis provides the detailed package and version breakdown.
- StepSecurity identified 444 unique packages and 2,212 compromised versions in its August 4 snapshot.
- Microsoft independently described the campaign as a self-propagating worm affecting more than 400 npm packages.
- The first confirmed malicious release identified by StepSecurity was
keyv@6.0.0. - The malware uses npm installation hooks, stolen credentials and automated package publishing to spread.
- Researchers found collection mechanisms for npm, GitHub, cloud, Kubernetes, Vault and several AI development environments.
StepSecurity identified keyv@6.0.0 as the first confirmed malicious release in the campaign, published at about 09:35 UTC on August 4. The package has a large download base, and the researchers also identified malicious releases of packages including flat-cache@6.1.24 and file-entry-cache@11.1.6.
The initial set identified by StepSecurity contained 11 packages that acted as the first worm carriers. They included packages in the Keyv and Cacheable ecosystems such as cacheable-request@13.0.20, @cacheable/utils@2.5.1, cacheable@2.5.1, @cacheable/memory@2.2.1, cache-manager@7.2.10, @cacheable/node-cache@3.1.2, ecto@5.0.1 and @cacheable/net@2.1.1.
StepSecurity said the initial compromise was followed by propagation into hundreds of other packages. Among the namespaces recorded in its investigation were @servicetitan, with 141 packages; @onereach, with 78; @or-sdk, with 74; @ornikar, with 42; and @qlik, with 28. Smaller affected namespaces included @nebula.js, @umacloud, @arv-bedrock, @deliveroo, @picsart and @adminide-stack. The investigation also recorded 26 additional unscoped packages.
Microsoft’s security research independently described the campaign as a self-propagating worm. Its analysis found that stolen npm publishing credentials could be used to enumerate packages controlled by a compromised identity and publish infected versions without requiring the attacker to manually compromise each package.
The malicious packages typically use an npm preinstall lifecycle hook to start the attack. StepSecurity found files including setup.mjs, Math_Symbol.js and, in later waves, math_init.js. The first-stage loader can check whether the Bun JavaScript runtime is present and, when necessary, retrieve a legitimate Bun release before using it to execute the second-stage payload.
StepSecurity measured the main second-stage payload at about 727,680 bytes and found extensive obfuscation and embedded resources. The researchers said the code was designed to collect sensitive information from both developer workstations and automated build environments.
The stolen information can include npm and GitHub credentials, cloud credentials, Kubernetes configuration, HashiCorp Vault material, SSH keys, environment files and other secrets.
Palo Alto Networks’ Unit 42 analysis independently documented collection attempts involving AWS and other cloud credentials, Docker and Helm configuration, Git credentials, npm and GitHub tokens, PyPI and RubyGems credentials, Terraform state, Vault and Kubernetes credentials, as well as data stored by developer tools.
The campaign also searches for credentials associated with modern AI development tools. StepSecurity identified paths associated with environments including Claude Code, Codex, Cursor, OpenAI, Anthropic, Gemini, OpenClaw, OpenCode and Kiro. The findings show that the attackers were not limiting collection to traditional package-manager or cloud credentials.
One of the more significant techniques identified by researchers involves GitHub Actions runners. Unit 42 found an embedded Python component that can locate the Runner.Worker process and inspect its memory for secrets and OpenID Connect credentials. This allows the malware to seek credentials that may exist in memory during a build even when they are not permanently stored as files.
The malware can also use compromised GitHub credentials to modify repositories. StepSecurity observed files such as .vscode/tasks.json, .vscode/setup.mjs, .claude/settings.json and .claude/setup.mjs being used as persistence mechanisms. Unit 42 found that these configurations could execute code through development-tool startup or session hooks, creating another route for malicious code to reach developers working with an affected repository.
ChainDrop also uses blockchain infrastructure to locate command-and-control servers. StepSecurity identified an Ethereum smart contract at 0xE1f2395ee43e45A1556EC6438a88c31B83493103 that stores command-and-control information and can be updated by the operator. The researchers observed npm-cache.com among the infrastructure used for data exfiltration.
The use of an Ethereum contract allows the operator to change the infrastructure that infected systems contact without necessarily releasing another version of the malicious package. StepSecurity said the stolen data is compressed and encrypted before transmission and found evidence that the server can return JavaScript to the infected system.
The campaign’s publishing process also raises concerns about software provenance. StepSecurity found malicious releases that were published through legitimate GitHub Actions workflows and carried valid provenance attestations. That means provenance could show that a package came from the expected build process while the source or release process itself had already been compromised.
This distinction is important because a valid build record does not by itself prove that the code entering the build was authorized. In the ChainDrop investigation, attackers were able to abuse trusted publishing mechanisms after obtaining control of maintainer credentials and development workflows.
StepSecurity also found evidence of the malware executing in public GitHub Actions runs associated with the Backstage project.
The researchers said they identified 15 matching runs, including five of their own test runs and 10 associated with Backstage. They did not find evidence that long-lived repository credentials were stolen from those Backstage runs, because the affected jobs did not contain repository secrets and the GitHub token available to the jobs was ephemeral.
Developers and organizations that may have installed an affected package should establish which versions were present and whether the malicious installation scripts actually executed. Microsoft recommends treating systems that executed affected packages as potentially compromised, rotating exposed credentials from a clean environment and rebuilding affected systems and downstream artifacts from trusted sources.
For the prominent initial packages, StepSecurity listed the following known-good versions: keyv@5.6.0, flat-cache@6.1.23, file-entry-cache@11.1.5, cacheable@2.5.0, cacheable-request@13.0.19, cache-manager@7.2.9 and ecto@5.0.0.
The incident is part of a broader series of npm supply-chain attacks that have increasingly targeted developer credentials, CI/CD systems and package publishing workflows.
Microsoft has previously documented campaigns involving malicious npm packages, stolen publishing credentials, CI/CD runner memory scraping and packages carrying legitimate publishing provenance. Its broader Shai-Hulud research provides context for the techniques that have appeared across this family of attacks.
Researchers have linked ChainDrop technically to the wider Shai-Hulud family, but the available evidence does not establish that a specific previously named group conducted the August campaign. The safest description is therefore a self-propagating npm supply-chain attack that used stolen credentials and compromised publishing workflows to spread across unrelated packages and development environments.
The 444-package figure remains one of the clearest measurements from the incident, but it should be presented as StepSecurity’s August 4 snapshot, not as an immutable final total. As researchers continued examining the campaign, different investigations recorded different numbers of packages and versions.
The consistent finding across the research is that ChainDrop was designed to move beyond an individual malicious package and use compromised developer and publishing credentials to create further infections.
References: StepSecurity’s ChainDrop forensic analysis; Microsoft Security’s ChainDrop investigation; Palo Alto Networks Unit 42 research; Microsoft’s Shai-Hulud research.
Discover more from Aree Blog
Subscribe now to keep reading and get access to the full archive.
