Shai-Hulud Returns: When Software Trust Becomes the Attack Surface
The August 2026 Shai-Hulud campaign was more than another npm compromise, it reflected the evolution of software supply chain attacks, where build pipelines and trust mechanisms have become high-value targets.
The August 2026 npm worm compromised one of the JavaScript ecosystem’s most-used caching libraries and spread to more than 400 packages within hours. It is the maturing of a trend in which the software build pipeline, and the trust mechanisms meant to protect it, have become the attack surface. This is what changed in the attackers’ tradecraft and what CISOs should do about it.
Executive Summary
On August 4, 2026, the largest Shai-Hulud supply chain wave to date compromised the widely used `keyv` caching library and its related packages, spreading to more than 400 npm packages and over two billion monthly installs within hours. This was not an isolated event. It is the maturing of a trend that has been building since the first Shai-Hulud worm in September 2025 where the software build pipeline and the trust mechanisms meant to protect it have themselves become the attack surface.
This publication explains what changed in the attackers’ tradecraft in 2026, why signing and provenance are necessary but no longer sufficient, and which controls actually contain the damage in case of an attack or a failure. Most of the core defenses are not new. This most recent wave raises the stakes on sound controls and add a few pipeline-specific controls.
Key Takeaways
- The target has shifted from the package to the pipeline. Attackers now publish through legitimate release workflows, so poisoned artifacts carry valid provenance and pass signature checks.
- Provenance confirms origin, not intent. Do not treat a passing signature or provenance check as proof that a package is safe.
- Attackers’ command and control is now decentralized: the malware resolves its endpoints from an attacker-controlled blockchain contract. This technique defeats static blocklists, but default-deny egress from build environments defeats it, because the malware can no longer reach the blockchain node to resolve an endpoint. The contract is also public, so defenders can read and pre-block its endpoints.
- Persistence now reaches the developer endpoint and the AI coding assistant, so editor and assistant configuration must be included in endpoint monitoring.
- Any compromised organization with publishing privileges becomes a distribution node, so the first response question is whether you are only a victim or also a distributor.
- Response sequence matters: remove persistence, then rotate credentials, then purge caches and rebuild. Rotating first can trigger destructive behavior.
Background: From the First Shai-Hulud Worm to the August 2026 Wave
In September 2025, a self-replicating worm the community came to call Shai-Hulud changed the economics of open-source supply chain abuse. A single phished maintainer credential became the seed for automated propagation across hundreds of npm packages, with the payload racing to harvest developer and cloud credentials before defenders could react. Sygnia wrote about that first wave as it unfolded in Supply Chain Attacks in Q4 2025: From Isolated Incidents to Systemic Failure Modes), including how little time defenders had to respond and how systematically the worm harvested credentials and secrets across hundreds of organizations.
Watching the incidents accumulate through late 2025, we flagged an early signal: these were not isolated package compromises but early signs of a systemic shift, one in which the pipelines and trust mechanisms meant to protect software could themselves become the attack surface. Through 2026 those signals hardened into a clear trend, and the smaller “mini” Shai-Hulud waves along the way each pushed it a step further.
On August 4, 2026, that trend produced its largest expression yet. Attackers compromised the account behind `keyv`, one of the most widely used caching libraries in the JavaScript ecosystem, along with the maintainer’s related packages including `flat-cache`, `file-entry-cache`, and `cacheable`. Within hours, the worm had spread to more than 400 packages representing over two billion monthly installs. The compromise followed a pattern that had been growing all year across the SAP developer ecosystem, TanStack, and the AntV data-visualization libraries, where the target is no longer just the package. Instead, it is the build pipeline and the trust attached to it.
How Shai-Hulud’s Tradecraft Changed in 2026
The worm mechanics are recognizable from 2025, but the tradecraft has advanced in several material ways. The changes below are the ones a CISO should internalize, because they go against assumptions that many defensive programs rely on.
1. Publishing Through Legitimate Release Pipelines, Not Just Stolen Tokens.
Earlier waves published malicious versions using stolen npm tokens. The 2026 waves increasingly ride the victim project’s own release workflow. In the August wave, the attacker pushed malicious code directly to the `main` branch and cut a normal release. In the May TanStack wave, the attacker poisoned a GitHub Actions cache from a fork pull request and waited for a legitimate maintainer merge to execute it during the release job.
2. Valid Provenance on Malicious Artifacts.
Because publication happened through the genuine release pipeline, the poisoned packages carried valid SLSA (Supply-chain Levels for Software Artifacts) provenance attestations, signed through npm’s Sigstore-based trusted publishing. This is the uncomfortable evolution of the trend: provenance proves which pipeline produced an artifact, not that the pipeline was behaving as intended. Signature and provenance checks alone will pass on these packages.
3. Broader Credential Harvesting.
The secret-stealing surface keeps widening to cover cloud credential chains, CI tokens, Kubernetes and Vault secrets, SSH keys, and local developer material, including scraping CI runner process memory for values that were masked in logs. This is an extension of 2025 behavior rather than a new capability, and it reinforces the lesson learned that any secret reachable from a build environment should be treated as already exposed.
4. Resilient, Decentralized Command and Control.
The most notable shift in the August wave is infrastructure. Rather than hardcoding a command-and-control (C2) domain, the payload resolves its fallback endpoint dynamically by reading an attacker-controlled Ethereum smart contract. The operators can rotate infrastructure at will without ever touching the malware, and static domain or IP blocklists are defeated by design. Exfiltration compounds this by abusing trusted destinations: encrypted credential bundles are written into attacker-created public GitHub repositories, blending into ordinary developer traffic.
This is the single most interesting change, and it is more easily stopped than it first appears. The resolution step has two chokepoints the attacker cannot avoid. First, the malware still must reach a public blockchain node or gateway to read the contract, and build systems have no legitimate reason to call Ethereum RPC (Remote Procedure Call) endpoints. Default-deny egress from CI and build infrastructure, with an allowlist limited to your registry, source host, and known release endpoints, breaks the lookup before it starts, and any attempt to reach a blockchain gateway from a build runner becomes a high-confidence alert. Second, in the variants observed so far, the contract stores the endpoint in the clear at a fixed, public address, so defenders can read exactly what the attacker reads: the current set of resolved C2 endpoints can be enumerated straight from the chain and pre-blocked, and the contract can be watched so that new endpoints are captured the moment the operators rotate them. The decentralization that makes takedown hard also makes the attacker’s live infrastructure observable.
Encrypting or obfuscating the on-chain endpoint by the attacker raises the cost of analysis but cannot keep it secret from defenders who can observe the malware resolving it at runtime.1
5. Persistence into Developer and AI Tooling.
The payload installs persistence that survives reboots and blends into modern developer workflows: VS Code tasks that run on folder open, session hooks in AI coding assistants such as Claude Code, injected CI workflow files, and OS-level services and token-monitoring daemons.
Persistence itself is not new to this class of supply-chain worms. Earlier waves already used injected CI workflow files and install-time hooks to re-establish themselves, and pipeline-level persistence is something we have long treated as a thing to hunt for. What is new is where the persistence now reaches: the local developer endpoint and the AI assistant running inside it. The workstation and its coding assistant are now part of the persistence surface, which means editor and assistant configuration must be pulled into standard endpoint monitoring rather than trusted implicitly.
6. Worm Propagation as the Default.
Once credentials are stolen from one environment, the worm enumerates every package the victim can publish and pushes infected versions using stolen tokens or, where available, OIDC (OpenID Connect) trusted publishing. Any compromised organization is therefore not only a victim but a distribution node for the next set of victims.
Mitigation: What Should Have Been Done?
The good news is that the core mitigations are not new. Sygnia has been recommending most of them for a while, and the 2026 waves do not rewrite the playbook so much as increases the importance controls that were already sound, while adding a few pipeline-specific controls.
Fundamental Recommendations:
- Pin dependencies and commit lockfiles; install with npm ci rather than resolving semver ranges at build time. Caret and tilde ranges are what turn a single poisoned version into a fleet-wide exposure.
- Disable install-time scripts by default (npm install –ignore-scripts) and allowlist only the packages that genuinely need them. The preinstall, install, and postinstall scripts run automatically for direct and transitive dependencies, which is the worm’s main entry point. GitHub is making them opt-in in npm version 12 (July 2026), so adopting this now puts you ahead of that default.
- Introduce a package cooldown so newly published versions are not adopted immediately, giving detection time to catch a malicious release.
- Rotate and scope secrets aggressively; minimize long-lived tokens and cloud credentials available to build environments.
- Prepare before the incident. Keep a current map of every secret, token, and credential reachable from each build and CI environment, where it is stored, and how it is rotated, plus a rehearsed rotation runbook. When a compromise is confirmed, this lets you rotate in the correct order within minutes instead of reconstructing scope under pressure.
- Treat removal from the public npm registry (registry.npmjs.org) as incomplete. Poisoned copies remain in your internal mirror or proxy (Artifactory, Nexus, Verdaccio, GitHub Packages), CI caches, and each developer’s ~/.npm, and will keep serving the bad version after the upstream takedown. Purge those caches and block the specific version in your internal repository.
New or Elevated for the 2026 Pipeline-Abuse Model:
- Do not treat valid provenance or passing npm audit signatures as proof of safety. Provenance confirms origin, not intent.
- Lock down GitHub Actions cache and fork pull-request behavior. Fork PR workflows should not be able to write caches that privileged release workflows later consume.
- Constrain OIDC trusted publishing: restrict which workflows can mint publish tokens, and monitor token requests tied to pull-request or fork refs.
- Rotate credentials in the correct sequence. Remove attacker persistence before revoking tokens; some variants monitor token validity and trigger destructive actions on revocation.
- Move build and CI egress to default-deny with a narrow allowlist. Decentralized C2 that resolves from a blockchain contract defeats domain blocklists, but it cannot survive a build environment that is not permitted to reach arbitrary internet or blockchain endpoints in the first place. Where full allowlisting is not feasible, read the contract to enumerate its currently resolved endpoints, block those, and monitor the contract for rotation.
Detection: What Should Have Been Done?
Our prior guidance emphasized behavioral detection over static indicators, because worm variants rotate quickly. That guidance holds, and the August wave’s decentralized C2 only reinforces it. Static blocklists age out in hours; behavior does not.
Previous Recommendations, Still Where Detection Starts:
- Alert on install-time script execution that spawns shells, network callouts, or unexpected runtimes during npm install or build steps.
- Monitor CI/CD for unexpected outbound connections and for publish events that do not correspond to an intended release.
- Baseline and monitor developer and build identities for anomalous package publishing.
Hunt Signals Specific to the Current Waves.
These are the highest-value indicators, not a full detection rule set. The detailed detection logic and hunt queries belong in a companion technical reference rather than in this post.
- Behavioral detection criteria based on Auditbeat, Windows Security, and Sysmon process-execution logs:
- Process name is one of:
bun,bun.exe - Command line references one of:
Math_Symbol.js,math_init.js
- Process name is one of:
- Suspicious packages: unexpected files at the package root, install or prepare scripts that run obfuscated code, and a published size that differs sharply from prior clean versions.
- Suspicious build behavior: a process reading build-runner memory, an unexpected runtime being fetched or executed mid-build, publish or token-request events tied to fork or pull-request refs, and build agents connecting to blockchain endpoints.
- Persistence: run-on-open editor tasks, session hooks in AI coding assistants, injected workflow files, and unfamiliar user-level services or token-monitoring daemons.
- Exfiltration: new public code repositories created under corporate or developer accounts, and commits from unexpected identities.
- Provenance as a lead, not proof: attestations tied to unexpected release workflows warrant investigation.
Next Steps for the CISO
1. Assume exposure and scope it. Determine whether any affected package families entered your environment during the exposure windows, directly or transitively. Treat any build host or developer machine that installed an affected version as potentially compromised.
2. Run the propagation-node test first. Establish whether any compromised environment had npm publishing privileges, GitHub write access, or OIDC publishing access, and whether anything was published, deployed, or released afterward. This determines whether you are only a victim or also a distributor.
3. Sequence the response correctly. Remove persistence, then rotate credentials, then purge caches and rebuild from verified-clean sources. Rotating before removing persistence can trigger destructive behavior and will not stop re-infection.
4. Harden the pipeline, not just the dependency list. Prioritize the controls that the 2026 model specifically defeats: fork PR and cache isolation, OIDC publishing restrictions, install-script suppression, egress allowlisting, and cooldowns. These convert a systemic failure mode back into a contained incident.
5. Reframe the board conversation. The strategic message is unchanged from when supply chain attacks first appeared: software supply chain trust mechanisms are themselves an attack surface. Provenance, signing, and trusted publishing are necessary but not sufficient to keep malicious code out, because a poisoned artifact can carry valid provenance and a good signature. Defense has to extend into the build pipeline and the developer endpoint, not stop at the registry.
References and further reading
For more information, see:
– https://www.sygnia.co/threat-reports-and-advisories/supply-chain-attacks-in-q4-2025/
– https://github.blog/changelog/2026-06-09-upcoming-breaking-changes-for-npm-v12/
- Encryption would prevent passive extraction of the endpoint from the blockchain, but the malware must ultimately obtain a usable plaintext destination. Defenders can therefore recover either the decryption material or the resolved endpoint through static or dynamic analysis of a malware sample. Encrypting the endpoint solely with an attacker-controlled asymmetric key would be ineffective because the malware could not decrypt it; embedding the required private or symmetric key in the malware would make that key recoverable. ↩︎
Omer Kidron, Enterprise Security Expert <br> Lahav Meir, Senior Enterprise Security Expert. (2026, August 5). Shai-Hulud Returns: When Software Trust Becomes the Attack Surface, Sygnia.
https://sygnia-stg.prpl.global/threat-reports-and-advisories/shai-hulud-returns-software-supply-chain-attack-npm-keyv/
Related Resources
By clicking Subscribe, I agree to the use of my personal data in accordance with Sygnia Privacy Policy. Sygnia will not sell, trade, lease, or rent your personal data to third parties.