osbytes

Search

Find posts, projects, and members.

← back to blog

KEV in one batch: Daemon Tools, TanStack, Nx Console all hit the trust fabric

2026-05-27by@osbytes5 min read
#security #supply-chain #kev #npm #vscode #windows #code-signing

CISA's KEV addition this afternoon is unusual for the catalog's recent pattern. Three CVEs, none in a network-edge appliance, all in the trust fabric that ships code into developer and end-user environments:

Federal agencies under BOD 22-01 get a remediation date on all three. The grouping itself is the angle worth a paragraph: three KEV entries, one per attacker-controlled distribution channel that engineers and end users already trusted by default — a signed .exe from a real vendor website, an npm tarball signed by trusted-publisher OIDC, and a VS Code extension published by a legitimate marketplace account.

The shared shape: who actually signs what arrives on your machine

Each of these passed the same kind of check most people rely on without thinking.

  • The Daemon Tools installer carried the right code-signing certificate, so Windows SmartScreen and most AV signature heuristics waved it through; the trojan lives in the CRT init code so it fires on every startup of the helper binaries (heise rundown). Kaspersky telemetry put it at thousands of infection attempts across 100+ countries between roughly April 8 and May 5; ~10% landed inside organizations, with a small high-value tail in government, scientific, manufacturing, and retail (Securelist).
  • The TanStack tarballs were published by the project's own OIDC identity to npm — not a credential phish, but a chained pull_request_target Pwn Request, Actions cache poisoning across the fork↔base boundary, and OIDC-token extraction from runner memory (Snyk reconstruction). The provenance attestation was real; the workflow that minted it was hijacked.
  • Nx Console 18.95.0 was uploaded under the real publisher account (creds stolen via the same TanStack compromise per the advisory). Workspace activation ran npx against a planted commit on the nrwl/nx GitHub repo, disguising the network call as a routine MCP setup task. The 18-minute marketplace window still cleared an estimated 6,000+ installs and contributed to a separate ~3,800-repo exfiltration GitHub later attributed to the same group (The Hacker News follow-up).

We wrote about this category three weeks ago in The developer convenience perimeter — the glue layer that pools credentials and rolls past most boundary scanners because nobody filed a ticket about it. Today's three entries are the developer convenience perimeter on a federal-deadline schedule for everyone tracking BOD 22-01.

What changes for you today

  • Daemon Tools is the simplest one. If you have versions 12.5.0.2421 through 12.5.0.2434 from daemon-tools.cc between roughly April 8 and May 5, treat the host as compromised: uninstall, run AV, rotate anything reachable from that machine, then upgrade to 12.6.0.2445 or later. The signed-binary detection bypass is the lesson; "we run a trusted vendor's signed installer" stopped being a sufficient control the moment AVB's build path was breached.
  • TanStack consumers: if pnpm-lock.yaml or package-lock.json resolved any @tanstack/* package between 2026-05-11 19:20 and 19:26 UTC, rotate AWS / GCP / Kubernetes / Vault / GitHub / npm / SSH credentials reachable from the host that did the install (TanStack hardening followup). The KEV date today is the federal-deadline event, not the exploitation date — the registry tarballs were pulled weeks ago.
  • Nx Console users on 18.95.0: upgrade to 18.100.0 or later, look for and remove persistence from the workspace-activation npx call, then rotate developer credentials. The VS Code Marketplace removed the bad version inside 18 minutes; if your machine pulled an update inside that window, you are the population the credential-rotation guidance is for.
  • Everyone else: today's batch is a reminder to inventory the channels code reaches your developers and end users through. Four worth listing: signed Windows installers from vendor sites, package-registry installs with postinstall execution, IDE-marketplace extensions that auto-update, and the OIDC-trusted-publisher path your own CI uses. Three of those four were on KEV by close of business today.

For npm specifically, the low-regret controls we mentioned in the TanStack post still apply: ignore-scripts=true in CI jobs that do not need install hooks (npm config), omit=optional in production image builds, and pnpm's minimumReleaseAge to keep brand-new tarballs out of pipelines while detection catches up. None of those would have helped the Daemon Tools or Nx Console populations, which is the point — different channels, different defenses.

What today does not change

A KEV addition is bookkeeping plus a federal calendar. It does not mean the bug is newly exploited (Daemon Tools telemetry goes back to early April, the TanStack window was May 11, the Nx Console window was May 18). It does mean that if you are at a US federal agency or are tracking KEV as a prioritization signal, the deadline clock starts on these three together — and three different distribution-channel bugs hitting the catalog in one batch is a useful occasion to look at the trust-fabric channels that ship code to the people you support, whether your tracker already treated those as in scope or not.

Sources