Inside the Shai-Hulud Supply Chain Attack: How Keyv and Friends Were Compromised on npm

The Attack Play-by-Play

On April 16, 2025, the npm ecosystem took another hit. The keyv package—a simple key-value store with over 10 million weekly downloads—was compromised, along with several packages in its orbit: cacheable, cacheable-lookup, and cacheable-request. The attack chain, dubbed "Shai-Hulud" by Aikido Security researchers, wasn't a novel zero-day. It was a precision strike through a compromised maintainer account, and it unfolded with the efficiency of a well-oiled CI/CD pipeline gone rogue.

The entry point was a stolen npm access token belonging to a maintainer with publish rights to the targeted packages. The attacker didn't just push a single malicious version. They published a sequence of versions across the dependency tree, each carrying an obfuscated payload tucked inside the package's postinstall script. That's the hook that fires automatically after npm install completes—no user interaction required beyond the install itself.

Here's the technical timeline:

1. Token compromise: The maintainer's npm token was exfiltrated, likely through a credential leak, a compromised local machine, or a phishing attack. The exact vector remains undisclosed, but the result was full publish access.

2. Coordinated publishes: Over a short window, malicious versions were pushed to keyv, cacheable, cacheable-lookup, and cacheable-request. The version numbers were carefully chosen to blend into the expected semver range, making them look like routine patches.

3. Obfuscated postinstall scripts: Each malicious version contained a postinstall script that decoded and executed a second-stage payload. The payload established a reverse shell to a command-and-control (C2) server, giving the attacker persistent remote access to any environment that installed the compromised package.

4. Dependency cascade: Because keyv depends on cacheable, and cacheable depends on cacheable-lookup and cacheable-request, a single npm install keyv pulled in the entire compromised tree. The blast radius was amplified by the fact that many downstream packages—HTTP clients, caching layers, and CLI tools—depend on these libraries transitively.

5. Detection and takedown: Aikido Security's research team spotted anomalous publishes and reverse-engineered the payload. npm's security team was notified and unpublished the malicious versions within hours. But as with any supply chain attack, the window of exposure for teams running automated builds during that period was real.

The Payload, De-obfuscated

The postinstall script used layered obfuscation—base64 encoding, string splitting, and hex encoding—to hide its intent. Once decoded, the logic was straightforward: determine the OS, establish a TCP connection to a hardcoded C2 domain, and spawn a shell. The attacker could then execute arbitrary commands, exfiltrate environment variables, or pivot to other systems.

This pattern is textbook supply chain exploitation. The attacker doesn't need to crack your infrastructure. They just need to sit inside a package you already trust, wait for your CI runner to npm install, and collect the keys to your kingdom.

Why This Matters for Engineers and FDEs

Supply chain attacks like Shai-Hulud hit differently when you're a Forward Deployed Engineer (FDE). You're not just shipping internal code—you're deploying into customer environments, often with elevated access, and you're moving fast. The trust model between your code, your dependencies, and your customer's infrastructure is the entire game.

The FDE-Specific Risk Profile

FDEs operate at the intersection of engineering and customer success. You're prototyping integrations, building custom tooling, and shipping scripts that run inside enterprise networks. A compromised dependency in your toolchain doesn't just mean a red alert on your monitoring dashboard. It means a potential breach at a customer site, a frantic call with their security team, and a serious erosion of trust.

Consider this scenario: you're building a Discord Community FAQ Bot for a customer, pulling in an HTTP caching library that transitively depends on keyv. Your n8n workflow runs npm install inside a Docker container that has access to the customer's Supabase instance. If that install happens during the compromise window, the attacker's reverse shell now has a foothold inside the customer's infrastructure. The blast radius extends far beyond your own laptop.

Or take the case of an On-Call Incident Summarizer that reads production logs. A compromised dependency in that pipeline could leak sensitive log data, PII, or internal system architecture to an external C2 server. The tool you built to reduce toil becomes the attack vector.

The Trust Chain Is Only as Strong as Its Weakest Maintainer

The Shai-Hulud attack reinforces a brutal truth: npm's security model trusts maintainers implicitly. When a maintainer's token is compromised, the attacker inherits that trust. There's no mandatory 2FA on publish (though npm has made strides here), no code review requirement, and no automated behavioral analysis that flags a package suddenly shipping obfuscated postinstall scripts.

For FDEs, this means every package.json you ship is a liability statement. You're vouching for every direct and transitive dependency. When you're Debugging in the Dark without environment access, the last thing you need is a compromised package adding noise—or worse, exfiltrating the limited access you do have.

How to Audit and Harden Your Own Pipelines

This isn't a theoretical exercise. Here's how to actually check if you were exposed and how to lock things down going forward.

1. Check Your Lockfiles Immediately

Run this against your projects:

grep -E "keyv|cacheable|cacheable-lookup|cacheable-request" package-lock.json yarn.lock

If you see any of these packages, check the resolved version against npm's advisory database. The malicious versions were unpublished, but if your lockfile pinned one of them, you're still referencing it locally. Delete your node_modules and lockfile, then reinstall from a clean state.

2. Audit Postinstall Scripts Across Your Dependency Tree

The postinstall hook is the attacker's favorite vector because it's silent and automatic. You can audit every postinstall script in your tree with:

find node_modules -name "package.json" -exec jq -r 'select(.scripts.postinstall) | "\(.name): \(.scripts.postinstall)"' {} \;

This requires jq. The output will list every package that runs code after install. Review anything that looks obfuscated, calls out to external domains, or downloads additional payloads.

3. Pin and Hash Your Dependencies

Semver ranges are convenient, but they're also a supply chain attack's best friend. A ^5.0.0 range will happily pull in 5.0.1-malicious if it's the latest satisfying version. Use exact versions in package.json and commit your lockfile. Better yet, use a tool like npm-audit-ci or snyk in your CI pipeline to block builds on known vulnerabilities.

4. Run Installs in Isolated Environments

Your CI runner should not have access to production secrets during the install phase. Use multi-stage Docker builds where the npm install stage has zero access to environment variables, API keys, or network egress beyond the registry. If a postinstall script fires, it should find nothing but a barren sandbox.

5. Monitor for Anomalous Publishes

If you maintain packages yourself, set up notifications for new publishes. Tools like npm-watch can alert you when a dependency you rely on ships a new version. The faster you know, the faster you can pin a known-good version before your CI pulls the bad one.

6. Use a Dependency Firewall

For enterprise deployments, consider routing all npm traffic through a proxy like Verdaccio or JFrog Artifactory. These act as a caching layer and can block packages that match certain heuristics—obfuscated scripts, first-time publishes from a maintainer, or packages that have changed ownership recently.

A Balanced Take on Open Source Risk

It's easy to read about Shai-Hulud and conclude that npm is a house of cards. That's the wrong takeaway. The npm ecosystem is massive, and the vast majority of maintainers are doing careful, thankless work. The attack surface is large because the value is enormous—millions of developers sharing code accelerates the entire industry.

The real lesson is that trust scales poorly. When you install a package, you're not just trusting the maintainer's intentions. You're trusting their opsec, their laptop's disk encryption, their password manager, and their ability to spot a phishing email. That's a lot of trust to place in a stranger who wrote a caching library in their spare time.

For FDEs, this isn't a reason to stop using open source. It's a reason to treat every dependency as a potential threat vector and to build your tooling accordingly. The same engineering rigor you apply to your own code—code review, sandboxing, least-privilege access—needs to extend to the code you didn't write.

If you're building a SQL Analyst Agent that queries a customer's production database, the dependency chain between your prompt and their data matters. If you're Generating Study Flashcards from Lecture Notes, the model weights aren't the only thing you should be scanning for safety. The Python packages that orchestrate the pipeline are just as critical.

The Shai-Hulud attack is a reminder that supply chain security isn't a compliance checkbox. It's an engineering discipline. And for FDEs who operate at the sharp edge of customer trust, it's non-negotiable.

FAQ

Q: Was I definitely compromised if I installed Keyv during the attack window?

Not necessarily. The malicious postinstall script established a reverse shell, but if your environment had egress filtering, no outbound internet access, or the C2 domain was blocked by your DNS, the payload may have failed to connect. That said, you should still assume compromise and rotate any secrets that were accessible to the install environment.

Q: How do I know if a package I maintain was affected?

Check your npm access tokens. If you use a CI token with publish rights, rotate it immediately. Enable 2FA on your npm account if you haven't already. Review your package's version history for any publishes you don't recognize.

Q: Are postinstall scripts the only attack vector?

No. preinstall, install, and postinstall scripts can all run arbitrary code. Attackers have also used prepublish scripts, test files that execute during npm test, and even malicious code embedded in minified JavaScript that runs at import time. The postinstall vector is just the most common because it requires zero user interaction beyond the install command.

Q: Can I disable postinstall scripts globally?

You can use npm install --ignore-scripts to skip all install scripts, but this will break packages that legitimately need to compile native addons or set up their environment. A more targeted approach is to use npm config set ignore-scripts true for your CI environment and then explicitly allow scripts for known-safe packages.

Q: What should I tell my customer if their environment was affected?

Be direct and technical. Explain the attack vector, the compromise window, and the steps you've taken to remediate. Provide a list of rotated secrets and a timeline. If you're operating as an FDE, your ability to handle this conversation with clarity and competence is what separates a trusted partner from a vendor on thin ice. For a deeper playbook on operating in constrained customer environments, see Debugging in the Dark.