How a Trusted Maintainer's Account Became a Weapon
The attack began around 9:00 UTC on August 4, when an attacker gained control of maintainer Jared Wray's GitHub account and used the legitimate publishing credentials attached to it. From that position, the attacker pushed malicious versions of ten core packages, including keyv, cacheable-request, cache-manager, and flat-cache, injecting two new files into each: setup.mjs and Math_Symbol.js. Both were wired into a preinstall hook, the npm lifecycle event that runs automatically the moment a developer or a CI pipeline runs npm install, before any human reviews a line of the new code.
That hook design is what made the attack so effective at scale. No developer had to open a file or approve a change for the payload to execute. Installing the package was itself the trigger, which means the compromise reached every automated build pipeline, every fresh developer environment, and every CI job that pulled a fresh copy of any affected package in the hours after publication. Combined, the ten core packages represent roughly two billion downloads a month, giving the attacker an unusually wide net for a single compromised account.
What the Payload Actually Did
Once triggered, the malicious code went hunting for credentials across the categories that matter most to an attacker planning further access: npm publishing tokens, GitHub personal access tokens, AWS keys, and HashiCorp Vault tokens. It validated stolen npm tokens in real time against npm's own registry, confirming which credentials were still live before using them, and it exfiltrated harvested data to an attacker-controlled domain alongside GitHub repositories set up to receive the stolen material. For infrastructure resilience, the payload used Ethereum smart contracts to serve as dynamic command-and-control infrastructure, a technique that makes takedown far harder than seizing a single domain.
The self-propagation is the detail that separates this from an ordinary credential-stealing campaign. Where a stolen npm token gave the attacker publishing rights to additional packages, the worm republished itself automatically under the compromised maintainer identities, extending its own reach without further manual effort. That mechanism is why the affected package count is reported as a range, 400 to 2,200, rather than a fixed number: researchers were still tracing new downstream infections as the campaign continued to spread through the dependency graph days after the initial compromise.
The Third Shai-Hulud Wave This Year
This is not an isolated incident so much as the latest entry in a pattern researchers now track under the Shai-Hulud name, referencing worm-like self-propagation through package ecosystems. April brought a compromise of PyTorch Lightning on PyPI. May brought an attack on the antv ecosystem linked to a group researchers call TeamPCP. August brought keyv and cacheable. No named actor has claimed the August campaign, and the initial access vector into Wray's GitHub account remains unknown, but the operational pattern across all three waves is consistent enough to treat as a single evolving threat rather than three unrelated incidents.
CrowdStrike's own 2026 threat hunting research backs up the trend line: the company found that 87 percent of identified software registry threats in the first half of 2026 involved malicious npm packages specifically, and separately tracked a single campaign that compromised more than 300 software dependencies in one day. Package registries have become a preferred initial access vector precisely because a single compromised maintainer account can reach downstream targets that would otherwise be well defended, skipping past perimeter controls entirely by riding in through the build pipeline.
Why AI Coding Tools Are Now Part of the Attack Surface
One detail in this campaign deserves specific attention from any organization that has adopted AI-assisted development: the payload included hooks designed to trigger via VS Code and Claude Code workspace settings, and it downloaded the Bun JavaScript runtime directly from GitHub as an evasion technique to run outside more heavily monitored Node.js execution paths. This is not evidence that AI coding assistants themselves were compromised. It is evidence that attackers are now deliberately mapping the developer tooling stack, including AI-assisted environments, when they design payloads meant to survive and spread inside modern engineering workflows.
The practical implication is that dependency security reviews written a year or two ago, before AI coding assistants were standard developer tooling, are reviewing an incomplete picture of the attack surface. Security teams should ask specifically how their AI coding tool integrations handle workspace-level automation, what execution privileges those integrations carry by default, and whether a compromised dependency could use those same integration points the way this payload was built to. This is a governance question for the platform team, not just a scanning question for the security team.
The Governance Decision This Puts on the Table
Chainguard's read on this incident is that organizations relying on the standard trust-on-install model, where a package runs its installation scripts the moment it is pulled, are structurally exposed to exactly this attack pattern regardless of how careful their own developers are. The fix is not developer vigilance. It is architectural: disabling lifecycle scripts by default for third-party dependencies, pinning exact package versions rather than accepting automatic minor updates, and running a private registry mirror that reviews packages before they reach a build pipeline rather than trusting the public registry directly at install time.
None of that is a quick fix, and most organizations will need budget and engineering time to implement it properly. That is exactly why this decision belongs with engineering leadership now, while the keyv incident is fresh and the business case is easy to make, rather than after the next wave lands inside an unprotected pipeline. Ask your platform team this week whether preinstall and postinstall scripts run unreviewed in your CI environment today. If the honest answer is yes, this campaign already had a path into your build systems, whether or not any of the ten specific packages happened to be in your dependency tree.
