Shai-Hulud Returns: Detecting the npm Supply Chain Attack Behind keyv, flat-cache, and 440+ Compromised Packages

The worm is back, and this time it hit the plumbing of the JavaScript ecosystem

On August 4, 2026, the Shai-Hulud npm supply chain attack resurfaced, and the worm went straight for packages that nearly every JavaScript application touches. After hijacking the GitHub account of maintainer Jaredwray, the attacker poisoned the keyv and cacheable package families, including keyv (~127M weekly downloads), flat-cache (~565M weekly downloads), file-entry-cache (~557M weekly downloads), and cacheable-request.

Then the worm did what worms do. Within an hour, it had self-propagated to more than 440 packages across 2,200+ package versions, reaching an estimated 2+ billion monthly installs. At the time of writing, a small number of malicious versions remain available on npm.

If your teams build with JavaScript, the question is not whether these packages are somewhere in your dependency tree. The question is whether you can find every affected application in minutes instead of days. This post covers how the attack works, the indicators of compromise to hunt for, and the detections that are already live in your ArmorCode tenant.

Why this attack is different

Unlike a traditional credential stealer, Shai-Hulud is a self-replicating supply chain worm. As in the earlier campaigns that hit TanStack and Mistral, it steals secrets from developer workstations and CI/CD runners, then uses those stolen credentials to publish itself into additional packages. Every newly infected package becomes a launchpad for the next wave. That is why the blast radius grew from one compromised maintainer account to hundreds of packages in under an hour.

How the Shai-Hulud npm supply chain attack compromised the keyv ecosystem

The attacker pushed two malicious files directly to the main branch of the maintainer’s repositories: setup.mjs and Math_Symbol.js. A new npm release followed immediately.

Here is the uncomfortable part: because the release originated from GitHub Actions, the compromised packages were published with valid Sigstore provenance. To most of the ecosystem, these looked like trusted releases.

Every compromised package received the same modification to package.json:

{
  "files": [
    "dist",
    "LICENSE",
    "setup.mjs",
    "Math_Symbol.js"
  ],
  "scripts": {
    "preinstall": "node setup.mjs"
  }
}

The actual library code inside dist/ remained byte-for-byte identical to the previous clean release, and the malicious behavior executes before installation completes. In other words, nothing about the package’s functionality changed, which made the compromise largely invisible to anyone diffing application behavior.

Stage 1: setup.mjs

setup.mjs is a lightweight, obfuscated dropper. It downloads a standalone Bun runtime and launches the second-stage payload under Bun. Running under a freshly downloaded Bun binary helps the malware evade endpoint monitoring that only watches Node.js processes.

Stage 2: Math_Symbol.js

Math_Symbol.js is a heavily obfuscated payload of roughly 728 KB. Its internal logging reveals four primary modules: [collector] harvests credentials, [dispatcher] coordinates execution, [provenance] handles package publishing metadata, and [publish] infects additional npm packages.

How the Shai-Hulud npm supply chain worm spreads

The infection cycle has four steps.

First, it harvests credentials: npm tokens, GitHub credentials, cloud secrets for AWS, Azure, and GCP, Kubernetes tokens, Vault tokens, SSH keys, .env files, Terraform state, Docker configs, and other sensitive files from developer machines and CI/CD runners.

Second, it self-propagates. Using stolen npm credentials, it identifies packages the victim can publish, injects the malicious preinstall hook, bumps the version, and republishes, often with valid Sigstore provenance.

Third, it establishes persistence by creating autostart hooks in .claude/settings.json and .vscode/tasks.json, so the malware re-executes whenever Claude Code starts or a VS Code workspace is opened.

Fourth, it exfiltrates. Stolen credentials are encrypted and uploaded to attacker-controlled GitHub repositories, with DNS and npm-cache[.]com available as fallback exfiltration channels.

Find your exposure in seconds with ArmorCode

Speed is everything in a supply chain incident. Every hour spent manually grepping lockfiles across hundreds of repositories is an hour the worm keeps spreading. ArmorCode customers have three ways to answer “are we affected?” right now, with no additional configuration required.

1. Ask Anya

Ask Anya, ArmorCode’s virtual security champion, directly. For example:

“Which of my applications are affected by the Shai-Hulud npm supply chain attack?”

“Show me all findings related to compromised keyv, flat-cache, and file-entry-cache versions.”

Anya surfaces affected findings across your portfolio with links to drill down by application, component, and severity, so you can go from question to remediation owner in one conversation.

2. Findings page: pre-built saved view

A pre-built saved view, “Shai-Hulud Supply Chain Attack (Aug 2026)”, is available on the Findings page. It covers all compromised namespaces and versions from this campaign across your connected scanners, giving you a single triage queue instead of scanner-by-scanner spreadsheet work.

3. SBOM page: saved views

Saved views under the “Shai-Hulud Supply Chain Attack (Aug 2026)” folder on the SBOM page show every application and component in your inventory that includes a compromised package or version, even where scanners have not yet flagged a finding. This is where continuous SBOM monitoring pays off: you see exposure by what you actually ship, not just by what scanners have caught up to.

Indicators of Compromise (IOCs)

Shai-Hulud is a case study in how fast a single maintainer account compromise can cascade into an ecosystem-scale npm supply chain attack. The defenses that matter here are the unglamorous ones: lockfile enforcement, restricting broad SemVer ranges, dependency version cooldowns so brand-new releases age before adoption, trusted publishing, continuous SBOM monitoring, and automated supply chain risk detection.

The other half of the equation is response speed. ArmorCode enables security teams to identify and respond to npm supply chain incidents within seconds. Anya, the Findings saved view, and the SBOM saved views described above are live in your tenant now, with no configuration required.

If you are an ArmorCode customer, open the “Shai-Hulud Supply Chain Attack (Aug 2026)” saved view or ask Anya about your exposure. If you are not yet a customer and spent today grepping lockfiles by hand, request a demo and see how much faster the next incident response can be.

Key Takeaways

1. The npm supply chain attack hit npm’s plumbing. Shai-Hulud compromised keyv, flat-cache, and 440+ other packages (2B+ monthly installs) in under an hour by self-propagating with stolen credentials.

2. The malicious code hid in the install step. A preinstall hook ran malware before the app even started, while the library code itself stayed unchanged, so behavior diffs would not have caught this npm supply chain attack.

3. ArmorCode customers can check exposure in seconds. Ask Anya, or use the pre-built Shai-Hulud npm supply chain attack saved views on the Findings and SBOM pages, no configuration needed.