CVE Is Not a Security Strategy: Why Waiting for an Advisory Is the Wrong Move in the Supply Chain Era

Part 2 of The Rise of Supply Chain Attacks: Why 2025–2026 Changed Everything

In my last post I argued that the supply chain is no longer a side door — it is the front door. The Mini Shai-Hulud campaign that compromised TanStack, Mistral AI, OpenSearch, and Guardrails AI in May 2026 makes a second argument impossible to avoid: the CVE system, as a security signal, is structurally unfit for what is now happening.

CVE is not enough

This is not a critique of CVE’s authors or the NVD maintainers. It is a recognition of what CVE was built to do — and what it was never designed to handle.

What CVE Was Built For

The Common Vulnerabilities and Exposures system assumes a world where:

A vulnerability — a defect in software logic — exists in a named, versioned component.
A researcher or vendor discovers it, often after exploitation.
A disclosure process begins: coordination, patch development, advisory writing, NVD enrichment.
Defenders consume the advisory, map it to their inventory, and patch.

That cycle — from discovery to actionable advisory — takes days at best, weeks routinely, and months when coordination goes badly. It is a fundamentally reactive and asynchronous model. It describes the world of 2014, when the hardest supply chain problem was a forgotten OpenSSL version in a VM image.

It does not describe the world of 2026.

The TanStack Incident Is the Case Study

On May 11, 2026, Socket’s threat research team detected 84 compromised npm artifacts across the @tanstack namespace. The malicious versions contained router_init.js — a 2.3 MB, fully self-contained supply chain worm. It was flagged within six minutes of publication.

Let me be precise about what the word “worm” means here, because the technical details matter to the argument:

The payload harvested credentials from GitHub Actions, AWS (including IMDSv2), HashiCorp Vault, and Kubernetes service accounts — hitting every major secrets plane in cloud-native CI.
It exploited GitHub Actions’ OIDC federation mechanism to mint a valid npm publish token without ever stealing a static credential, then republished itself under the stolen maintainer identity.
It persisted onto developer workstations by writing into Claude Code’s hook directory (.claude/settings.json) and VS Code’s task runner — ensuring it re-executed every time a developer opened the project, even after npm uninstall.
Exfiltration was routed through Session’s decentralized P2P network (filev2.getsession[.]org), making C2 traffic indistinguishable from encrypted messaging app telemetry at the network layer.
It submitted valid Sigstore provenance attestations after publishing — meaning malicious packages carried a “verified provenance” badge that would pass cursory security reviews.

Now ask yourself: what CVE number covers this?

There is no exploited software defect here. OIDC token federation is working exactly as designed. npm lifecycle hooks (prepare, postinstall) are working exactly as designed. GitHub Actions cache sharing across fork-to-base boundaries is a documented behavior, not a zero-day. The createCommitOnBranch GraphQL mutation is a public API. Claude Code’s hooks configuration is a documented feature.

The attacker did not break anything. They used everything correctly — and none of it will ever get a CVE.

The CVE Gap Is Not a Bug, It’s Architecture

The CVE system has an explicit scope boundary: it covers vulnerabilities, defined as flaws in design, implementation, or configuration that can be exploited to violate the security policy of a system. Abusing a legitimate, correctly-functioning feature — a lifecycle hook, an OIDC federation trust, a GitHub Actions permission — does not fit that definition.

This is not a gap someone forgot to close. It is a deliberate architectural choice. CVE is a catalog of defects. Supply chain attacks in 2026 are increasingly not about defects. They are about abusing trust relationships between legitimate, correctly-functioning systems.

Consider the chain TanStack’s postmortem describes:

A pull request is opened from a fork — legitimate GitHub behavior.
The pull_request_target trigger fires with write permissions — documented, but dangerous, behavior.
Attacker-controlled code runs during a CI workflow — the intended purpose of the runner.
A GitHub Actions cache is poisoned across the fork-to-base boundary — a known risk, not a CVE.
An OIDC token is extracted from the runner process memory and exchanged for an npm publish token — working as designed.
84 package artifacts are published to the npm registry under the legitimate maintainer’s identity — valid npm publishes.

At no point does a vulnerability occur. At no point does CVE apply. And at no point does your vulnerability scanner — faithfully ingesting NVD feeds and matching against your SBOM — fire a single alert.

The Time Problem Makes It Worse

Even in cases where a CVE could theoretically be assigned — say, a malicious package version that gets a CVE entry after the fact — the timeline is catastrophic.

The Mini Shai-Hulud campaign was detected at publication by behavioral analysis. Socket flagged the malicious @tanstack artifacts within six minutes. The CVE process, if it were applicable, would take weeks. By then:

Thousands of CI pipelines would have executed the payload.
GitHub Actions OIDC tokens would have been exchanged for npm publish rights on additional packages.
Those additional packages would have propagated the worm further.
Developer workstations would have persistent implants in .claude/ and .vscode/ directories that survive the npm uninstall that follows the eventual advisory.
Exfiltrated credentials would have been used — the attacker’s own message, signed from git-tanstack.com, confirmed they had been “online over 2 hours now stealing creds” while the investigation was still in progress.

My previous post quoted a practitioner observation worth repeating: the compromise date and the impact date are not the same date. CVE, even at its fastest, closes that gap with an advisory. It does not close it with prevention.

What the Campaign Is Also Teaching Us About “Secure” Signals

There is a more uncomfortable lesson buried in the technical analysis. The compromised TanStack packages carried valid Sigstore provenance attestations. An attacker who can execute in GitHub Actions can generate valid Sigstore signatures for malicious packages — because the signature proves the package was built in Actions, not that the Actions run was clean.

This matters because the security industry has spent considerable effort pointing to provenance attestations, signed commits, and SBOM generation as the answer to supply chain risk. They are valuable controls. They are not sufficient controls. If your threat model only includes “someone tampered with the package after it was signed,” these tools help. If your threat model includes “the build pipeline itself was compromised before signing” — which is the model that the last eight months demand — they provide false confidence.

The same logic applies to CVE-based tooling layered on top of SBOMs. An SBOM accurately reflecting @tanstack/react-router@1.x.y with no known CVEs would have been entirely correct and entirely useless on May 11, 2026.

So What Does Actually Work?

I am not arguing for abandoning CVE-based vulnerability management. It remains necessary for the large class of exploitable software defects that still exists, and deprioritizing it creates a different class of exposure. The argument is narrower: CVE cannot be the primary or the last line of defense for supply chain risk. You need controls that operate at a different layer and on a different timeline.

A few principles that follow from the TanStack analysis:

Behavioral detection at publish time. Socket’s six-minute detection was not based on a signature or a CVE match. It was based on behavioral heuristics: a newly added large obfuscated file, spawn-based daemonization patterns, access to CI-specific environment variable namespaces, P2P exfiltration endpoints. Defending at this layer means catching threats that have no CVE, no prior signature, and no advisory — because they are new.

Install-time enforcement, not audit-time. If your supply chain policy runs after npm install, you have already executed the payload. The persistence mechanisms in router_init.js — the .claude/settings.json hook, the .vscode/tasks.json task — survive after the package is removed. Controls need to block at install, not report after.

Quarantine windows on new versions. The previous post made this point and it bears repeating with the TanStack numbers behind it. Packages with 12 million weekly downloads pushed malicious versions that were live for a window before detection. A 24–72 hour automatic quarantine on newly published versions — enforced at the CI level, not the advisory level — would have kept those versions out of most pipelines. This is a policy, not a product. It costs nothing to implement in your CI configuration.

Scope restriction on OIDC federation. The TanStack attack pivoted on a CI workflow that had id-token: write permissions in a job that also executed pull-request-origin code. The remediation — restrict id-token: write to only the specific publish job, add repository_owner guards, pin third-party actions to commit SHAs — is documented in TanStack’s own postmortem. These are configuration changes. Apply them today without waiting for a CVE to mandate them.

Treat persistence paths as IOCs. The presence of router_runtime.js in .claude/ or an unfamiliar entry in .vscode/tasks.json is now an active indicator of compromise tied to this campaign. Post-incident tooling — git log --all --author=claude@users.noreply.github.com — can surface worm-authored commits across your repositories. Add these checks to your incident response runbooks now, not when a future advisory references them.

Re-examine what “clean” means in your SBOM. An SBOM is a point-in-time snapshot. A package version that was clean at the time of the last scan may not be clean today. The Mini Shai-Hulud campaign introduced malicious versions while leaving prior versions untouched. Continuous scanning — not periodic — is the only model that closes this gap.

The Harder Shift

The practical controls above are table stakes. The harder shift is cultural and organizational.

The CVE-based model creates a comfortable illusion: if there is no CVE, there is no known risk. Security teams run scanners, triage findings by CVSS, and close tickets. The process is auditable, the metrics are clean, and the risk register looks manageable. This is exactly the wrong framing for supply chain threats that do not generate CVEs, propagate in hours, and persist after the package is removed.

The campaigns I covered in the last post, and the TanStack incident that prompted this one, share a pattern: they are industrialized, they are automated, and they are faster than the feedback loops defenders are relying on. A worm that harvests OIDC tokens and republishes itself across 84 packages in the time it takes to write a CVE description is not a problem the CVE system was designed to solve.

Defenders who treat “no CVE assigned” as “no action required” are operating on a model that attackers already know how to route around.

The supply chain is the front door. The attackers have a key. Waiting for someone to file a report about the key is not a security strategy.

If you found this useful, the IOCs from the TanStack incident — file hashes, network indicators, and persistence paths to hunt — are documented in full in Socket’s technical analysis. TanStack’s own postmortem with hardening recommendations for the pull_request_target pattern is at tanstack.com/blog/npm-supply-chain-compromise-postmortem.