CISA KEV: Nx and TanStack Supply-Chain Response

CISA’s May 27 KEV additions are a warning about the developer trust layer, not just another vulnerability queue. When malicious code reaches IDE extensions and npm packages, remediation has to include exposure review, credential rotation, and proof that trusted tooling did not become an attacker’s launchpad.

CISA added CVE-2026-48027 for Nx Console and CVE-2026-45321 for TanStack to the Known Exploited Vulnerabilities catalog on May 27, 2026, with a June 10, 2026 remediation due date for federal civilian agencies. The KEV entries describe malicious code published through trusted software distribution paths: a compromised Nx Console extension and malicious TanStack npm package versions that could harvest credentials under a trusted project identity (CISA KEV JSON catalog).

For private-sector teams, the lesson is bigger than the federal deadline. These are software supply-chain compromises where “update the package” is necessary but not sufficient. If malicious code executed on a developer workstation or CI runner, the response has to answer what secrets were reachable, which accounts were used afterward, and whether the build system can prove it is clean.

What happened in the Nx and TanStack KEV additions?

The Nx Console issue, tracked as CVE-2026-48027, involved malicious version 18.95.0 of the Nx Console extension. The Nx advisory says the compromised version was available in the Visual Studio Marketplace from 12:30 UTC to 12:48 UTC and in OpenVSX from 12:33 UTC to 13:09 UTC, and it identifies 18.100.0 as the safe version (Nx Console GitHub advisory).

The TanStack issue, tracked as CVE-2026-45321, involved 84 malicious versions across 42 @tanstack/* packages published to npm between approximately 19:20 and 19:26 UTC on May 11, 2026. The TanStack advisory says the malware executed during package installation and targeted credentials from developer and CI environments, including cloud credentials, Kubernetes service-account tokens, Vault tokens, npm tokens, GitHub tokens, and SSH private keys (TanStack GitHub advisory).

CISA’s KEV entry for Nx says the compromised extension fetched an obfuscated payload that could harvest credentials from disk and memory, while the KEV entry for TanStack says malicious package versions were published to npm under a trusted identity to distribute credential-stealing malware (CISA KEV JSON catalog).

If you worked through our earlier Mini Shai-Hulud analysis of the TanStack compromise or the OpenSearch npm compromise post, this guide focuses on the KEV-driven response decisions that follow once the incident is on the federal exploitation list.

Why is this different from a normal patch ticket?

A conventional patch workflow asks whether vulnerable software is present and whether a fixed version is installed. A developer-toolchain compromise asks a harder question: did trusted software run attacker-controlled code in a place where credentials, source code, deployment rights, or CI secrets were available?

That difference changes the response. Updating Nx Console to 18.100.0 or moving TanStack packages to patched versions closes known exposure paths, but it does not invalidate a GitHub token, npm token, cloud key, SSH key, or Vault token that may already have been read from disk, memory, a CI environment, or a build runner.

This is why KEV-driven supply-chain response should merge vulnerability management with incident response. The work is not complete when the scanner turns green. It is complete when the organization can show which systems were exposed, what executed, what credentials were reachable, what was rotated, and what telemetry was reviewed.

Who should prioritize this today?

Prioritize the response if any of the following apply:

Development teams use Nx Console in Visual Studio Code or OpenVSX-compatible environments.
Applications use TanStack packages such as TanStack Router, Start, router plugins, devtools, adapters, or framework-specific packages.
CI/CD pipelines ran dependency installs during the TanStack exposure window or pulled from npm caches that may contain malicious package versions.
Developer endpoints store credentials locally, including GitHub tokens, npm tokens, cloud credentials, SSH keys, or gh CLI credentials.
Build runners have long-lived secrets or broad permissions to publish packages, deploy infrastructure, or access source repositories.
Security tooling inventories operating systems but not IDE extensions, package lockfiles, or CI runner activity.

Organizations in regulated environments should treat this as a control-validation event. It tests whether software inventory, endpoint telemetry, secrets management, CI/CD logging, and developer access governance can work together under time pressure.

What should security teams do in the first 24 hours?

Start with a narrow exposure sprint, then expand based on evidence.

Identify affected developer systems and CI jobs

For Nx Console, find developer systems that installed or auto-updated to version 18.95.0 during the marketplace exposure windows. The Nx advisory recommends updating to version 18.100.0 or later and treating affected machines as potentially compromised because the malicious extension could harvest credentials (Nx Console GitHub advisory).

For TanStack, search lockfiles, package manager caches, build logs, artifact metadata, and CI dependency-install history for affected @tanstack/* versions listed in the advisory. The TanStack advisory says any developer or CI environment that ran npm install, pnpm install, or yarn install against an affected version on May 11 should be considered compromised (TanStack GitHub advisory).

Rotate credentials that were reachable

Credential rotation is the center of the response. The TanStack advisory calls for rotating credentials accessible to the install process, including AWS, GCP, Kubernetes, Vault, npm, GitHub, and SSH credentials (TanStack GitHub advisory).

The Nx advisory similarly recommends rotating every credential reachable from affected machines and auditing access logs for affected accounts (Nx Console GitHub advisory).

Do not rotate only the obvious token. If the compromised context was a developer workstation, include local SSH keys, package registry credentials, GitHub CLI credentials, cloud profiles, environment variables, service-account files, and any credentials used by local build tooling.

Preserve logs before they age out

Preserve endpoint telemetry, EDR process trees, shell history where policy permits, package manager logs, CI job logs, GitHub audit logs, npm access logs, cloud audit logs, and secrets-manager access logs. The goal is to reconstruct whether malicious code executed, what it could reach, and whether any credentials were used from unexpected locations afterward.

Remove persistence and unsafe artifacts

The Nx advisory includes cleanup guidance for suspicious processes and persistence artifacts, including __DAEMONIZED and cat.py processes and macOS LaunchAgent handling (Nx Console GitHub advisory).

Treat cleanup as evidence-driven. Capture artifacts before deletion where appropriate, then rebuild or reimage developer systems when confidence is low.

How should teams harden developer tooling after remediation?

The post-incident work should reduce the chance that a trusted update path becomes an unreviewed execution path again.

Govern IDE extensions like executable software

Editor extensions run inside privileged developer contexts. Security teams should inventory installed extensions, restrict unapproved publishers, review auto-update policy, and monitor extension version drift. For high-trust environments, consider approved extension baselines for developer groups with production, package-publishing, or infrastructure access.

Reduce secrets on developer workstations

Long-lived credentials on endpoints increase blast radius. Prefer short-lived tokens, device-bound conditional access, just-in-time elevation, hardware-backed SSH keys where appropriate, and central secrets management over static files in home directories.

Make CI runners disposable and least-privileged

CI runners should have short-lived credentials, scoped permissions, egress monitoring, immutable build images, and clear logs for dependency installation. If a runner executes untrusted package lifecycle scripts, assume the runner can expose whatever secrets are in its environment.

Treat package lifecycle scripts as a risk boundary

Package install scripts are code execution. For sensitive pipelines, evaluate whether lifecycle scripts can be disabled by default, selectively allowed, or run inside hardened sandbox contexts. The TanStack advisory recommends configuring npm to skip lifecycle scripts with npm config set ignore-scripts true as part of remediation guidance (TanStack GitHub advisory).

Connect vulnerability management to identity response

For developer-toolchain KEV items, remediation tickets should include identity tasks: token invalidation, key rotation, access-log review, and suspicious-use detection. A “patched” status without credential assurance is incomplete.

What evidence should leaders ask for?

Executives and risk owners do not need every package version detail, but they should ask for a concise assurance package:

Exposure scope: which teams, repos, endpoints, CI jobs, and packages were in scope.
Version evidence: current Nx Console versions and affected TanStack package search results.
Credential actions: which credential classes were rotated and when.
Telemetry review: which logs were reviewed, for what timeframe, and what was found.
Exceptions: systems or teams not yet verified, with owners and deadlines.
Control improvements: changes to IDE extension governance, CI/CD secret scoping, package install policy, and developer endpoint monitoring.

This turns an urgent KEV response into a durable improvement in software supply-chain resilience.

Frequently asked questions about the Nx and TanStack KEV additions

What did CISA add to KEV on May 27, 2026?

CISA added CVE-2026-48027 for Nx Console and CVE-2026-45321 for TanStack to the KEV catalog on May 27, 2026, with a June 10, 2026 due date for federal civilian agencies under BOD 22-01 (CISA KEV JSON catalog).

What Nx Console version was compromised?

The Nx advisory identifies Nx Console 18.95.0 as compromised and lists 18.100.0 as the safe version. The malicious build was available in the Visual Studio Marketplace from 12:30 to 12:48 UTC and in OpenVSX from 12:33 to 13:09 UTC (Nx Console GitHub advisory).

What happened with TanStack packages?

The TanStack advisory says 84 malicious versions across 42 @tanstack/* packages were published to npm between approximately 19:20 and 19:26 UTC on May 11, 2026, and that the malware ran during install to harvest developer and CI credentials (TanStack GitHub advisory).

Is updating the package or extension enough?

No. Updating is required, but both advisories call for credential rotation and access-log review when affected systems may have executed malicious code (Nx Console GitHub advisory, TanStack GitHub advisory).

Which credentials should be rotated?

Prioritize credentials reachable from affected developer systems or CI jobs, including GitHub tokens, npm tokens, SSH keys, cloud credentials (AWS, GCP), Kubernetes service-account tokens, Vault tokens, and local CLI credentials (TanStack GitHub advisory).

How can teams prevent repeat incidents?

Inventory IDE extensions, govern package install behavior (including lifecycle scripts), minimize long-lived local secrets, isolate CI runners with short-lived credentials and scoped permissions, review dependency install logs, and connect vulnerability response with identity and secrets response.

Why does KEV matter if we are not a federal agency?

KEV listing reflects evidence of active exploitation. Private-sector organizations should treat it as a high-confidence prioritization signal even where BOD 22-01 does not apply — especially for compromises that pivot from a single developer endpoint into source control, CI/CD, and cloud accounts.

References

Cyberuptive runs a 24/7 follow-the-sun SOC staffed by U.S.-based analysts, headquartered in Honolulu and serving customers across Asia-Pacific and the U.S. mainland. We help mid-market organizations, MSPs, and Pacific defense subcontractors turn supply-chain alerts into evidence-backed response: developer endpoint exposure review, CI/CD telemetry analysis, credential-rotation planning, vulnerability management, SOC monitoring, and executive-ready reporting.

Read our vulnerability scanning services, our patch management services overview, and our SOC-as-a-Service overview, or talk to us about a no-obligation review of your exposure to KEV-listed developer-toolchain compromises.