Two unrelated supply chain compromises — one a live npm registry attack against the TanStack open-source JavaScript ecosystem, the other a years-old ASUS Live Update client backdoor only now confirmed exploited — landed in CISA's KEV catalogue within roughly two weeks of each other, illustrating two structurally different ways attackers weaponize trust in a software distribution pipeline.
| CVE | CVSS | Vendor | Mechanism | Added to KEV |
|---|---|---|---|---|
| CVE-2026-45321 | 9.6 | TanStack | Malicious npm packages published via compromised GitHub Actions OIDC trust | 27 May 2026 |
| CVE-2025-59374 | 9.8 | ASUS | Backdoored Live Update client builds distributed to end-of-life devices | 17 Dec 2025 |
Why the TanStack incident is a case study in how modern CI/CD trust actually breaks
NVD's description of CVE-2026-45321 is unusually precise for a supply chain finding, and worth reading closely: over a six-minute window on 11 May 2026, 84 malicious versions across 42 @tanstack/* packages were published to npm. Critically, the publishes were authenticated through TanStack/router's legitimate GitHub Actions OIDC trusted-publisher binding — the publish workflow itself was never modified. The attacker instead chained three separate, individually known vulnerability classes: a pull_request_target "Pwn Request" misconfiguration, GitHub Actions cache poisoning across the fork-to-base trust boundary, and runtime memory extraction of the OIDC token from the Actions runner process itself. None of those three techniques is new in isolation — each has independent prior research and public writeups — but chaining them together let the attacker publish credential-stealing malware under TanStack's own trusted publishing identity, meaning every downstream consumer that trusted "this came from TanStack's official pipeline" had no signal that anything was wrong. That is precisely the property that makes modern CI/CD trusted-publishing schemes attractive to attackers: the entire design goal is removing the friction of manual credential handling, and this incident shows what happens when the automation trusted to remove that friction is itself compromised without anyone touching the publish workflow.
Why the ASUS case is the opposite failure mode: trust that was compromised at the source, then simply never expired
CVE-2025-59374 describes a different mechanism entirely. Certain versions of the ASUS Live Update client were distributed with unauthorized modifications introduced through a supply chain compromise — the client software itself, not a registry or CI pipeline, was the tampered artifact. NVD's description carries an unusual detail: the Live Update client reached end-of-support in October 2021, more than four years before this CVE was confirmed for active exploitation and added to KEV. The compromised builds were engineered to trigger only on devices "meeting specific targeting conditions," a hallmark of a deliberately narrow, precision supply chain implant rather than an opportunistic mass-compromise tool. CISA's KEV entry states plainly that "the impacted product could be end-of-life and/or end-of-service" and recommends discontinuing use entirely — there is no patch to apply because the vendor has no ongoing support obligation for this client, only a public notice describing what happened.
What to check this week
- Audit dependency lockfiles for any
@tanstack/*package version published in the 11 May 2026 window and pin to a version confirmed clean by TanStack's own postmortem rather than trusting a floating version range to have self-corrected. - Review GitHub Actions workflows using
pull_request_targetin any internally maintained repository for the same fork-to-base trust boundary weakness this incident exploited — it is not unique to TanStack's specific configuration. - Inventory every device that has ever run ASUS Live Update and confirm none remain on the client past its 2021 end-of-support date, since CISA's guidance here is discontinuation, not patching.
- Treat CI/CD trusted-publisher bindings (OIDC, GitHub Actions publish tokens, npm provenance) as a distinct asset class requiring its own security review, separate from the code they publish — this incident shows the workflow can remain untouched while the trust mechanism around it is subverted.
A closing note on why both incidents evaded conventional patch-based remediation
Neither of these vulnerabilities has a conventional "apply this patch" remediation path in the way most KEV entries do. TanStack's fix was rotating credentials and hardening the CI pipeline, not shipping a new package version to replace a flawed one — the packages themselves were legitimate code with a malicious twin published alongside them. ASUS's guidance is outright discontinuation of an already-dead product. Vulnerability management processes built primarily around patch deployment need a parallel process for exactly this category: incidents where the fix is procedural (rotate credentials, rebuild trust bindings) or where there is no fix at all beyond removal.
A final consideration on npm and open-source ecosystem exposure
The TanStack incident's reference material explicitly connects it to a broader "self-spreading supply chain attack" pattern hitting the npm ecosystem more widely, described in industry research as "Mini Shai-Hulud." Organizations that consume any npm dependency, direct or transitive, from the broader JavaScript ecosystem should treat this incident as one confirmed data point in a wider and ongoing campaign rather than an isolated event fully resolved once TanStack's specific packages are pinned to clean versions.
How Safeguard helps
Safeguard's continuous inventory extends beyond traditional CVE-to-patch tracking to flag exactly this category of exposure — compromised software supply chains and end-of-life devices still running withdrawn client software — surfacing both the dependency-level risk from ecosystem-wide npm compromises and the fleet-level risk from devices that should have been retired years before their vulnerability was ever confirmed.
