The campaign, identified on August 4, 2026, began with the compromise of a GitHub account belonging to the maintainer of keyv, a key-value storage library with roughly 127 million weekly downloads. From there, attackers published malicious package versions containing a credential-harvesting payload, along with a self-propagating worm that uses stolen credentials to infect packages maintained by completely unrelated organizations.

By August 5, researchers had identified at least 444 compromised packages across 1,381 versions, representing more than 2 billion monthly installs. The campaign has continued to evolve.

The attack is tracked as a new iteration of Shai-Hulud, a supply-chain malware family previously associated with large-scale npm compromises. This time, the malware isn’t simply stealing secrets. It’s using those secrets to spread.

For background on how supply chain attacks of this type target developers, see our overview of open-source supply chain attacks targeting developers. For the trusted-software variant, see how UAC-0099 weaponized Notepad++ and WinRAR plugins. For a broader roundup of recent incidents, see our supply chain attack news coverage. The Shai-Hulud campaign is a documented real-world example of exactly what that coverage describes: a single maintainer account compromise that became an ecosystem-wide worm.

What Happened

The initial compromise targeted the GitHub account of the keyv maintainer. The attacker gained control of that account and used it to modify the package source and publish a malicious release.

The first confirmed malicious release was keyv@6.0.0, along with a set of dependent packages: flat-cache, file-entry-cache, cacheable-request, cacheable, @cacheable/memory, cache-manager, @cacheable/node-cache, @cacheable/utils, and @cacheable/net.

These packages sit deep inside dependency trees, so organizations don’t need to have explicitly installed keyv to be exposed. Socket identified dependency chains in which widely used tools like ESLint indirectly depend on packages within the compromised ecosystem.

This is one of the defining characteristics of supply-chain attacks: the victim doesn’t need to trust the attacker. They only need to trust their dependencies.

How the Malicious Package Stays Hidden

One of the most concerning aspects of this attack is how little the malicious release changes on the surface.

In keyv@6.0.0, researchers found that the package’s normal dist/ output was byte-for-byte identical to the clean release. The malicious functionality was instead introduced through package.json and additional files, specifically a lifecycle hook:

preinstall: node setup.mjs

This means the malicious code executes automatically when the affected package is installed, before any application code runs. The setup.mjs loader then downloads a standalone Bun runtime and uses it to execute a second-stage payload. The package can behave exactly like the legitimate library while the installation process compromises the machine. That makes application-level code review significantly less effective as a sole control.

What the Malware Collects

The payload searches aggressively for credentials and secrets across the developer environment, targeting: npm authentication tokens, GitHub personal access tokens, GitHub App tokens, GitHub Actions OIDC credentials, AWS credentials and Secrets Manager access, Kubernetes service-account tokens and configuration, HashiCorp Vault and Terraform credentials, SSH keys and certificates, Docker registry credentials, Stripe API keys, Slack tokens, .env files, CI/CD credentials, and cryptocurrency-related keystores.

Wiz’s analysis notes that the latest version has significantly expanded its capabilities, now including credentials associated with AI development tools including Claude, OpenAI, Codex, Cursor, and Gemini, as well as additional CI/CD, cloud, and cryptocurrency infrastructure, becoming a true developer-environment credential harvesting framework.

From Credential Theft to Self-Propagation

The most important element of this campaign is what happens after credentials are stolen: the malware uses compromised npm credentials to identify packages the victim is authorized to publish, then injects malicious lifecycle hooks into those packages and publishes new, infected versions back to the npm registry. The newly infected package can then compromise another developer, who may have access to completely different packages, who can infect additional developers.

The result is a self-propagating supply-chain worm. This is why the scope expanded so quickly beyond the original keyv and cacheable namespaces. The first compromised maintainer was merely the first link in a chain of package compromises.

GitHub as a Second Propagation Layer

But the attack doesn’t stop at npm. The malware uses stolen GitHub credentials to modify repositories, with malicious hooks inserted into .claude/settings.json and .vscode/tasks.json in some cases. This means a developer could trigger malicious behavior merely by cloning an infected repository and opening it in their development environment, without even having to run npm install themselves.

The attack therefore targets multiple layers of the modern developer workflow: npm package installation, developer workstations, GitHub repositories, CI/CD runners, cloud credentials, and further npm packages. That dramatically increases the potential blast radius.

Provenance Checks Aren’t Enough

Perhaps the most uncomfortable lesson from this incident is that the compromised packages could still appear legitimate from a software provenance perspective. The attacker controlled the maintainer’s GitHub account and used the legitimate release workflow, so poisoned releases could carry valid provenance from the legitimate GitHub Actions build process.

A package can be correctly signed, correctly built, published through a legitimate CI pipeline, associated with the expected maintainer identity, and still be malicious.

Provenance tells you where software came from, but it can’t guarantee that the source it hasn’t itself been compromised.

Resilient Infrastructure

Stolen credentials are encrypted before exfiltration and can be uploaded to public GitHub repositories under compromised identities. Researchers identified repositories using the description “Shai-Hulud: Here We Go Again.”

More notably, the malware retrieves command-and-control infrastructure through an Ethereum smart contract, meaning the attacker can update parts of the infrastructure without publishing a new payload, making disruption harder.

What Security Teams Should Do Now

Organizations using npm should treat this as an active incident.

Identify affected packages and versions. Review dependency manifests and lock files across developer workstations, production applications, build systems, CI/CD runners, containers, and internal registries. Don’t limit the review to direct dependencies: examine the complete dependency tree.

Remove compromised versions. Affected versions should be removed and replaced with known-good releases. Upgrading alone is not sufficient if the malicious version already executed.

Assume credentials may be exposed. If an affected package ran in any environment containing credentials, treat those credentials as potentially compromised. Prioritize rotation of npm tokens, GitHub tokens, AWS credentials, cloud API keys, SSH keys, Kubernetes credentials, Vault tokens, Terraform credentials, and CI/CD secrets. Wiz specifically recommends treating systems that installed affected packages as potentially compromised and rebuilding where appropriate.

Investigate GitHub activity. Look for unexpected commits, force pushes, new repositories, unexpected package releases, suspicious GitHub Actions activity, changes to .vscode/tasks.json and .claude/settings.json, and unexpected OAuth applications or tokens.

Review cloud activity. If the affected package ran on a CI runner or cloud-hosted environment, investigate credentials available to that environment: unusual AWS API calls, new IAM credentials, Secrets Manager access, Kubernetes API activity, and Vault access.

Monitor for campaign indicators. Known infrastructure includes npm-cache\[.\]com, pypi-get\[.\]com, and js-mirror\[.\]com. Filename indicators include Math_Symbol.js, math_init.js, and setup.mjs. Researchers have published hashes and additional indicators in the sources linked below.

The Bigger Picture

The Shai-Hulud campaign is a reminder that modern organizations have an enormous external attack surface that doesn’t appear in traditional asset inventories.

Your organization may not own the npm registry, GitHub, a dependency’s maintainer account, an open-source library, or a third-party CI runner. But your organization may trust all of them. That trust creates an attack path.

Supply chain attackers understand this. Instead of attacking a large enterprise directly, they compromise a maintainer with access to a widely used package. Instead of stealing credentials from thousands of organizations individually, they compromise one developer environment and harvest what’s already there. The dependency ecosystem distributes the rest.

The immediate priority is containment: identify affected versions, remove them, assume credentials are exposed, rotate secrets, investigate downstream access, rebuild compromised environments, and monitor for continued propagation.

Supply chain security can’t stop at vulnerability scanning. Organizations need visibility into what they trust, who publishes it, how it’s built, what executes during installation, and what credentials are available to the environment running it.

At PhishFort, we track campaigns that weaponize trusted infrastructure against developers and brands. See how we monitor for supply chain threats and malicious ecosystem activity →

Sources:

• Aikido — Keyv and friends compromised in active Shai-Hulud supply chain attack
• Wiz Research — keyv and cacheable npm Package Hijacked in Supply Chain Attack
• Socket Research — Popular npm Packages in the keyv and Cacheable Namespaces Compromised in Active Supply Chain Attack