On August 4, 2026, attackers compromised the GitHub account of a maintainer behind several widely used npm packages, including keyv and cacheable.
What happened next demonstrates a dangerous weakness in many software development environments:
One compromised identity was able to become a trusted software publisher.
According to Aikido Security, the attackers pushed malicious files directly to the main branch and immediately created new releases. Because the legitimate GitHub Actions release process then published those releases, the poisoned packages even carried valid provenance.
In other words, the software could prove where it came from. It could not prove that the change should have been there in the first place.
What Happened in the ChainDrop Attack?
The campaign, commonly called ChainDrop, involved a self-propagating variant of the Shai-Hulud malware family.
After gaining access to the maintainer's GitHub account, attackers modified popular packages including keyv, flat-cache, file-entry-cache, cacheable, and others. Malicious code was inserted directly into their repositories and subsequently distributed through npm.
The malicious packages contained a credential-stealing payload capable of targeting sensitive information including:
.env filesWorse, the malware could use credentials stolen from infected environments to compromise additional packages and repositories, effectively turning the attack into a software supply-chain worm.
By August 5, Aikido reported at least 444 packages across 1,381 versions had been compromised, representing packages with more than 2 billion monthly installs combined. The exact number of downstream organizations ultimately affected remains unclear.
The malware was sophisticated. But the more important lesson may be much simpler. The attacker was able to push malicious code directly into main. There was no independent human standing between the compromised account and the trusted release path.
That matters because organizations frequently think about software security primarily in terms of protecting credentials:
Enable MFA. Protect GitHub accounts. Rotate tokens. Monitor suspicious logins.
Those measures are important, but ChainDrop illustrates why protecting an identity is not the same thing as protecting the software development process. Accounts can be compromised. Tokens can be stolen. Sessions can be hijacked.
The stronger question is:
If one trusted identity is compromised, can that identity change your production software by itself?
If the answer is yes, the organization still has a major control weakness.
This is where preventative software development controls become important.
CodeROI is designed to enforce controls inside the software development lifecycle, rather than relying solely on written policies that developers are expected to follow.
Organizations can require that changes satisfy specific conditions before they are allowed to move forward, including independent code review, required testing, designated approvals, and enforced separation of responsibilities.
In a properly configured CodeROI-controlled workflow, a single compromised developer or maintainer account should not be sufficient to move an unauthorized change through a protected development path.
For example, a malicious change could be required to:
The result is a materially different attack surface.
Instead of compromising one account, an attacker may need to compromise multiple independent identities and satisfy multiple enforced controls before malicious code can progress.
That does not make an attack impossible. It makes it harder. And that is exactly what good preventative security controls are supposed to do.
There is an important distinction. CodeROI would not necessarily have prevented the attackers from initially stealing or compromising the maintainer's GitHub credentials. That is primarily an identity and endpoint-security problem.
However, based on the reported attack path, CodeROI-style preventative controls could potentially have interrupted one of the most consequential steps of the attack: using a compromised account to push malicious software directly into a trusted development and release path.
Aikido specifically reported that malicious files were pushed directly to main before new releases were generated.
If that branch had been subject to system-enforced testing, independent approval, and separation of responsibilities that the compromised identity could not bypass, the attacker would have faced additional barriers before those changes could become trusted software. That distinction is critical.
Perhaps the most interesting lesson from ChainDrop is that the malicious releases reportedly had valid GitHub Actions provenance.
The release pipeline worked. The automation worked. The credentials worked. The problem was that the pipeline was operating on code that had already been compromised.
Cryptographic provenance can answer: "Where did this software come from?". Preventative SDLC controls answer a different question: "Was this change independently tested and authorized before we trusted it?. Modern organizations increasingly need both.
Most companies have software development policies.
Code should be reviewed. Testing should occur. Developers should not approve their own work. Production changes should follow defined procedures. But a policy that says something should happen is very different from a system that makes it impossible to proceed unless it happens.
ChainDrop is a reminder that attackers do not care what your SDLC policy says. They care about what your systems actually allow.
That is the philosophy behind CodeROI's Compliance platform: move critical software controls from documentation and human expectation into preventative, system-enforced restrictions inside the development lifecycle.
Because when one compromised account can become hundreds of compromised software packages, the safest development process is not one that simply asks people to follow the rules. It is one that enforces them.
What was the ChainDrop npm attack? ChainDrop was a software supply-chain attack discovered in August 2026 in which attackers compromised a GitHub maintainer account and injected credential-stealing malware into widely used npm packages. The malware could then steal additional credentials and propagate into other packages and repositories.
How many npm packages were affected by ChainDrop? As of Aikido Security's August 5 update, at least 444 packages across 1,381 versions had been compromised, with affected packages collectively representing more than 2 billion monthly installs. Because the campaign was actively spreading, counts reported during the incident varied.
How did the attackers modify the software? Aikido reported that malicious files were pushed directly into the main branch of compromised repositories before new npm releases were generated.
How can organizations reduce the risk of similar GitHub supply-chain attacks? Identity security remains essential, but organizations can reduce the impact of a single compromised account by technically enforcing protected development workflows, mandatory testing, independent approvals, and separation of responsibilities so that no single identity can independently introduce and approve sensitive software changes.
Sources:
Sources: Microsoft Threat Intelligence; Aikido Security; StepSecurity; and ITPro. Incident counts changed as investigators identified additional compromised packages, so figures in this article reflect reporting available during the August 4–5, 2026 investigation.