A fresh ChainDrop supply chain attack has targeted the NPM ecosystem by publishing a large number of compromised package versions. Researchers observed more than 2,200 malicious releases tied to 440 packages, making the incident notable not only for its scale, but also for how the attackers use stolen credentials to keep spreading.
According to reporting, the operation began after an attacker gained access to a maintainer’s GitHub account. From there, malicious packages were introduced into the NPM registry, and the poisoned releases were capable of executing harmful code as part of the normal installation process.
How the ChainDrop supply chain attack started
The campaign—tracked as ChainDrop—did not rely on a single infected project. Instead, it started with multiple malware carriers in specific NPM namespaces. Once the maintainer’s GitHub account was compromised, the attackers could create and publish altered package versions.
In total, the infected artifacts were widely used across the ecosystem. Researchers reported that the combined malicious packages generated over 500 million weekly downloads. That level of adoption increased the likelihood that many developers and CI/CD pipelines would install the tainted dependencies.
Poisoning through installation-time malware
Like earlier Mini Shai-Hulud supply chain incidents, the ChainDrop packages executed malicious code during installation. The compromised packages included a preinstall dropper that was designed to pull in the legitimate Bun JavaScript runtime and then load a second stage.
The second stage was reported as 710 KB of obfuscated code containing the actual malicious logic. After execution, the malware focused on collecting sensitive data from developer environments.
Secret theft and data exfiltration
The malware searched infected systems for the secrets it could find. It then processed the stolen information—described as encrypting it—before exfiltrating the results.
Exfiltration was reported to occur in two possible ways: either to a dynamic HTTPS endpoint or to attacker-controlled public GitHub repositories. Some of those repositories were created with a thematic description associated with previous campaigns.
Credential abuse across NPM, GitHub, cloud, and secret stores
One of the most concerning parts of the ChainDrop supply chain attack is that it doesn’t just steal credentials—it uses them. Microsoft’s assessment described that, after execution, the malware scans for credentials in multiple places, including developer workstations and CI/CD environments.
Those credentials could include NPM, GitHub, and cloud or infrastructure access details. The malware then used the recovered identities to authenticate to services such as NPM, GitHub, Amazon Web Services (AWS), Kubernetes, and HashiCorp Vault. With those permissions, it could enumerate resources such as packages, repositories, workflow secrets, cloud configuration values, and secret-store contents.
On top of that, JFrog reported that the malware leveraged stolen NPM credentials to publish poisoned versions of additional packages—effectively expanding the compromise scope on the fly.
Repackaging legitimate packages and spreading via GitHub Actions
After attackers obtained an NPM publishing token, the malware could enumerate packages accessible to the compromised identity. It would download current tarballs, insert the malicious payload and setup loader, add a preinstall hook, increase the patch version, and republish the modified package.
Microsoft also noted a persistence-related technique involving developer-to-developer propagation. The malware could use stolen GitHub credentials to inject configuration files for tools such as Claude and Visual Studio Code into repositories. This created an additional path for ongoing access and further compromise.
Large number of malicious iterations in a short window
The republishing behavior caused a fast increase in the total number of malicious iterations. StepSecurity reported that on August 4, researchers observed 2,212 malicious package iterations within less than four hours.
This rapid growth matters because it reduces the time window for detection and mitigation. If defenders rely only on delayed alerts, newly republished malicious versions may continue to be installed by automated systems.
Command-and-control and anti-persistence behavior
The ChainDrop supply chain attack also included mechanisms intended to make the malware harder to analyze and to keep control communications less predictable.
Researchers described the use of an Ethereum blockchain for command-and-control through a technique called EtherHiding. Instead of relying on a straightforward server list, the malware could reference control information using blockchain-based methods.
Dead-man’s switch and self-cleaning
Socket reported that the malware installed a host-level dead-man’s switch. After achieving persistence on macOS and Linux systems, it polled the GitHub API every 60 seconds using the victim’s stolen GitHub token.
If the token stopped working, the malware would delete its state and exit. Additionally, the worm was reported to self-clear after 24 hours, which may shorten the period during which infected systems appear active.
What developers and teams should do now
If any developer installed versions of the affected packages, the guidance is clear: treat the machine as potentially compromised. Because the malware can target secrets and attempt further republishing, incident response should focus on both cleanup and credential containment.
Jfrog recommended a structured approach that includes isolation and evidence preservation. They advised teams to:
- Isolate affected systems to stop further spread and data access.
- Preserve artifacts such as package tarballs, npm logs, CI logs, GitHub audit logs, and runner images before cleanup.
- Rebuild CI runners and build machines to remove persistence risks and ensure a clean environment.
- Revoke and rotate credentials that could be compromised, including tokens used in CI/CD and development workflows.
- Audit GitHub repositories for anomalous activity tied to publishing or configuration changes.
Preserving logs is especially important because it helps define the exposure window. In a supply chain case where malicious versions may be republished quickly, deciding what to rebuild and what to roll back depends heavily on timeline evidence.
Why this attack matters for the NPM ecosystem
The ChainDrop supply chain attack underscores a broader reality: compromised package publishing credentials can turn a one-time incident into a self-propagating campaign. By combining installation-time execution, secret discovery, credential reuse, and republishing logic, the attackers effectively scaled their impact.
For development teams, the takeaway is practical: treat dependency installs as part of your security perimeter. That means tightening access controls, monitoring for suspicious publishing behavior, and rapidly responding when indicators suggest compromised package versions.
Conclusion
The ChainDrop supply chain attack poisoned hundreds of NPM packages with thousands of malicious versions, executed payloads during installation, and used stolen credentials to expand the damage. If you installed affected versions—or if your CI/CD environment pulled them in—act quickly: isolate systems, preserve evidence, rebuild runners, and revoke potentially exposed credentials.
With supply chain threats continuing to evolve, preparedness and fast containment remain the best defenses against credential theft and ecosystem-wide dependency poisoning.
Source: https://www.securityweek.com/over-400-npm-packages-infected-in-chaindrop-supply-chain-attack/
