When a Worm Steals Your Keys, Blast Radius Is an Identity Question

TLDR: When a supply-chain worm like Shai-Hulud hits, you measure blast radius in identities, not packages. The worm harvests credentials, so your exposure is the set of non-human identities and secrets it could have taken, which of them were actually exposed and used, and what each one can reach. This piece gives you a 7-step method to answer "how bad is it" in an afternoon.

‍

On the morning of August 4, 2026, a self-replicating worm tore through the npm registry, compromising over 400 packages in hours. This included keyv, a caching library with 600 million monthly downloads, and a cluster of dependencies that underpin a massive portion of the world's JavaScript. This variant, dubbed CHAINDROP, is just the latest chapter in a cycle of supply-chain attacks that began last autumn. It won't be the last.

If you ship or buy software, your board and incident teams will ask one question: "How bad is it?" Answering it accurately is the difference between a controlled response and a week of high-stakes guessing.

Here's the answer most teams reach for too late: for a threat like Shai-Hulud, blast radius isn't a software inventory problem. It's a non-human identity (NHI) problem. The worm doesn't care about your code; it wants your credentials. Exposure isn't about which packages you installed, but which machine identities and secrets the worm could have harvested and what those credentials can reach.

‍

How does the Shai-Hulud worm work?

Shai-Hulud has struck four times since September 2025, getting faster and greedier each wave: the original September 2025 outbreak, the "Shai-Hulud 2.0" run that followed, the critical "Mini Shai-Hulud" hit on the TanStack ecosystem in April 2026 (CVE-2026-45321, CVSS 9.6), and now CHAINDROP. The objective never changes: credential theft.

Once a poisoned package is installed, it runs a secret scanner to grab npm tokens, GitHub PATs, and cloud credentials (AWS, Azure, GCP). In the latest wave, it also targets AI-tool keys for Anthropic, OpenAI, and Gemini. It then uses stolen npm tokens to republish itself into more packages, turning one compromised developer into a seed for a hundred more.

Crucially, npm install runs in CI/CD pipelines, not just on laptops. A single poisoned dependency can detonate inside your build infrastructure, where your most powerful credentials live, without a human touching anything. If you want a sense of how this plays out in practice, we broke down a real CI/CD identity compromise in our analysis of the tj-actions/changed-files incident.

‍

Why blast radius is a non-human identity problem

Look at the targets: npm tokens, PATs, cloud workload credentials, service-account keys, SSH keys, AI API keys. These are NHIs, the machine accounts and secrets that software uses to talk to other software. In most enterprises, NHIs outnumber human identities by 10 to 50 times, and they are the least governed of any identity you own: rarely rotated, often over-privileged, and frequently unowned.

This is why "which packages did we install" is the wrong lens. That list only tells you where the worm could have run. It doesn't tell you which credentials were sitting on those machines, if they were exposed, if they've been used, or what an attacker can do with them. Identity questions determine the impact.

Calculating blast radius means enumerating the NHIs and secrets the worm could have harvested, confirming genuine exposure, and determining what each one can reach. 

‍

How to determine blast radius in 7 steps

1. Define the scope. Use the worm's harvest locations as a filter. Inventory every NHI and secret matching its target list: secrets in AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager; cloud workload identities (IAM roles/users, Azure service principals, GCP service accounts) reachable via instance metadata; and machine credentials for npm, GitHub, or AI services. This defines your maximum theoretical exposure. 
2. Identify actual exposure. Not every secret in reach was stolen. Focus on secrets flagged as leaked or scanned, particularly those living on developer endpoints or inside CI/CD pipelines. This narrows your focus from "could have been taken" to "was likely taken."
3. Audit for active usage. Exposure is potential; usage is kinetic. Check usage telemetry for candidate credentials during and after the compromise window. A secret authenticating from a new geography or a dormant service account suddenly coming alive are active exploitation signals that demand immediate response.
4. Map the reach. A credential's danger is defined by its permissions. Flag over-privileged identities and toxic combinations. An admin-scoped service principal is a massive crater; a read-only token for a single bucket is a minor dent. This ranking turns a flat list of secrets into a prioritized action plan.
5. Filter by rotation status. Identify high-privilege, exposed identities that haven't been rotated since the compromise. Credentials configured never to expire are the highest risk. This intersection of confirmed-exposed, high-privilege, and unrotated is your top priority.
6. Assign ownership. A finding without an owner doesn't get fixed. Map every item in your ranked list to a name and a clear action: rotate or revoke. For npm and GitHub tokens, audit what they published or accessed after revocation.
7. Execute rotation at scale. Finally, rotate credentials without breaking dependent workloads. "Rotate everything" usually causes outages. You need dependency-aware coordination to finish the response safely.

The result is a ranked inventory of identities sorted by privilege, rotation state, and active use. That is the only useful answer to the blast radius question.

‍

Where the Oasis Platform fits

The Oasis Security platform begins by surfacing every non-human identity across your entire estate, spanning CSPs, SaaS, PaaS, and on-premises environments. Once inventoried, Oasis enriches this NHI landscape with live telemetry, consumer insights, human ownership mapping, and granular entitlement data. By applying intelligence-driven policies, the platform identifies high-risk anomalies and unrotated secrets in minutes. Beyond mere detection, Oasis integrates orchestrated remediation workflows to ensure compromised credentials can be rotated safely without disrupting critical business operations.

‍

Why does Shai-Hulud now steal AI API keys?

The August 2026 variant expanded to AI credentials because that's where the value is now. As organizations wire AI agents and autonomous workflows into their stacks, they are creating a new generation of NHIs faster than governance has met them. A worm that harvests secrets will take an Anthropic or OpenAI key alongside your AWS credentials, and those keys carry real spend, data access, and blast radius of their own.

The truth Shai-Hulud demonstrates is that the perimeter of a modern supply chain attack is your credential estate, and most of it is non-human. You cannot manually track tens of thousands of machine identities. You must maintain a live inventory of their exposure, privilege, and ownership so that when the next wave lands, "how bad is it" is a query you run in an afternoon, not a week-long crisis.

‍

How do you prepare for the next wave?

Four things to do before the fifth wave, not during it:

• Measure blast radius in identities, not packages.
• Know where your secrets live, and rotate never-expiring and dormant credentials now.
• Enforce MFA on package-publishing tokens.
• Make sure every high-privilege NHI has a clear, named owner.

Shai-Hulud has struck four times in under a year. A fifth wave is a matter of when, not if. Treat your non-human identities as the terrain where the fight will happen. When they are inventoried and owned, blast radius becomes a calculation instead of a panic.

‍

Oasis Security platform helps organizations discover, govern, and secure their non-human identities and AI agents,  mapping exposure, privilege, ownership, and rotation across cloud, SaaS, and on-premises environments. See how the Oasis Security Platform would scope your exposure to a supply-chain worm like Shai-Hulud. Request a demo.

‍

Sources

• CHAINDROP / Shai-Hulud (August 4, 2026) — Elastic Security Labs
• Mini Shai-Hulud FAQ, CVE-2026-45321 — Tenable
• Shai-Hulud 2.0 npm worm analysis — Datadog Security Labs
• Widespread Supply Chain Compromise Impacting npm (September 23, 2025) — CISA
• Shai-Hulud Returns: keyv, cacheable and 800+ npm Packages — Sygnia
• "Shai-Hulud" Worm Compromises npm Ecosystem — Palo Alto Networks Unit 42