CVE-2026-45321

What it actually does

This is a supply-chain compromise involving malicious npm releases of multiple @tanstack/* packages. The attacker abused a trusted publishing path by chaining a pull_request_target workflow misconfiguration, GitHub Actions cache poisoning across an untrusted fork-to-base boundary, and extraction of an OIDC token from a GitHub Actions runner process. The result was that malicious package versions were published to npm under a legitimate trusted-publisher identity, making them appear authentic. Downstream projects that installed or updated to the malicious versions could execute credential-stealing malware during dependency installation, build, test, server startup, or application runtime depending on how the package was consumed.

Why it matters to the business

Organizations using affected TanStack packages may have unknowingly pulled credential-stealing code from a trusted npm namespace, creating risk of leaked npm tokens, GitHub tokens, cloud credentials, CI/CD secrets, source-code access, production deployment credentials, and follow-on compromise. Because this issue is listed in CISA KEV, is marked as used in ransomware campaigns, and has a remediation due date of 2026-06-10, it should be treated as an urgent supply-chain incident rather than a routine package update. The operational impact can include emergency dependency review, credential rotation, CI/CD rebuilds, forensic investigation, and possible interruption of releases until affected builds are verified clean.

How an attack unfolds

An attacker first targets the upstream package publishing pipeline rather than a single downstream user. They exploit a pull_request_target GitHub Actions misconfiguration to influence workflow execution from an untrusted contribution context, poison Actions cache data that is later consumed by a privileged base-repository workflow, and then extract the GitHub Actions OIDC token from runner memory at runtime. With that token, they authenticate through the legitimate trusted-publisher relationship and publish malicious versions of @tanstack/* npm packages without visibly modifying the normal publish workflow. Downstream users are then compromised when package managers resolve to one of the malicious versions during install, update, CI, or deployment. Once installed, the malicious code can attempt to harvest credentials and secrets from developer workstations, build systems, CI environments, or runtime environments and exfiltrate them for further access, lateral movement, or ransomware operations.

How to fix it

Immediately identify all uses of affected @tanstack/* packages and determine whether any installed version was one of the two malicious versions published for each package between approximately 2026-05-11 19:20 and 19:26 UTC. No exact fixed versions were provided in the input, so do not assume a package is safe solely because it has a newer semver number; pin to maintainer-confirmed clean versions, versions published before the malicious window, or later versions explicitly confirmed by the TanStack maintainers as remediated. Regenerate lockfiles from trusted clean versions, remove node_modules and local package-manager caches after preserving evidence where needed, and rebuild artifacts from clean dependencies. Rotate any credentials that may have been accessible to affected developer machines, CI runners, build containers, or application environments, including GitHub tokens, npm tokens, cloud provider keys, SSH keys, deployment credentials, and service secrets. For maintainers and organizations operating similar publishing pipelines, harden GitHub Actions by avoiding privileged pull_request_target execution for untrusted code, isolating caches by trust level and event type, minimizing default GITHUB_TOKEN permissions, limiting OIDC permissions to specific release workflows, requiring environment approvals for publishing, and monitoring npm trusted-publisher events.

How to confirm the fix worked

Review package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, SBOMs, artifact manifests, container build logs, CI logs, and package-manager caches for affected @tanstack/* packages resolved to versions published between 2026-05-11 19:20 and 19:26 UTC. Use npm metadata, such as `npm view @tanstack/<package> time --json`, to compare installed versions against publish timestamps. Confirm that rebuilt applications resolve only to maintainer-confirmed clean versions. Validate that node_modules and package-manager caches no longer contain tarballs for malicious versions. Confirm that CI/CD systems have been rebuilt from clean dependencies and that potentially exposed credentials have been rotated. If any affected version was installed, treat the host or runner as potentially compromised and perform forensic review before returning it to service.

Typical attack path

1. Compromise or influence the upstream GitHub Actions workflow using a pull_request_target trust-boundary weakness.
2. Poison the GitHub Actions cache so untrusted content is later consumed by a privileged workflow context.
3. Extract an OIDC token from the GitHub Actions runner process during workflow execution.
4. Use the legitimate GitHub Actions OIDC trusted-publisher binding to authenticate to npm.
5. Publish malicious versions of affected @tanstack/* packages under the trusted package identity.
6. Wait for downstream developers, CI jobs, or deployment pipelines to install or update affected packages.
7. Execute credential-stealing code during package installation, build, test, application startup, or runtime.
8. Exfiltrate tokens, secrets, source-code credentials, npm credentials, GitHub credentials, or cloud credentials for follow-on compromise.

How to detect it

Investigate both dependency exposure and post-install compromise. For exposure, search source repositories, lockfiles, package-manager caches, CI logs, SBOMs, container image layers, and artifact manifests for affected @tanstack/* package names and compare resolved versions to npm publish times around 2026-05-11 19:20-19:26 UTC. Useful sources include package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, npm debug logs, CI job output, Docker build logs, artifact metadata, and dependency-scanning telemetry. For exploitation, review EDR, shell history, process execution, DNS, proxy, firewall, and cloud audit logs for suspicious activity shortly after npm install, yarn install, pnpm install, npm ci, build, test, or application startup events involving affected packages. Look for unexpected outbound network connections from CI runners or developer systems, unusual access to environment variables, token files, SSH keys, npm credentials, GitHub credentials, cloud metadata services, or secret stores, and anomalous use of credentials after the suspected installation time. If a malicious version was installed on a CI runner or developer endpoint, assume secrets accessible to that process may have been read and prioritize credential-use anomaly detection after the install time.

• @tanstack/arktype-adapter
• @tanstack/eslint-plugin-router
• @tanstack/eslint-plugin-start
• @tanstack/history
• @tanstack/nitro-v2-vite-plugin
• @tanstack/react-router
• @tanstack/react-router-devtools
• @tanstack/react-router-ssr-query
• @tanstack/react-start
• @tanstack/react-start-client
• @tanstack/react-start-rsc
• @tanstack/react-start-server
• @tanstack/router-cli
• @tanstack/router-core
• @tanstack/router-devtools
• @tanstack/router-devtools-core
• @tanstack/router-generator
• @tanstack/router-plugin
• @tanstack/router-ssr-query-core
• @tanstack/router-utils
• @tanstack/router-vite-plugin
• @tanstack/solid-router
• @tanstack/solid-router-devtools
• @tanstack/solid-router-ssr-query
• @tanstack/solid-start
• registry.npmjs.org/@tanstack/
• npm install @tanstack/
• npm ci
• yarn install
• pnpm install
• package-lock.json
• npm-shrinkwrap.json
• yarn.lock
• pnpm-lock.yaml
• node_modules/@tanstack/
• 2026-05-11T19:20
• 2026-05-11T19:21
• 2026-05-11T19:22
• 2026-05-11T19:23
• 2026-05-11T19:24
• 2026-05-11T19:25
• 2026-05-11T19:26

What your security team should do

• Treat this as an active supply-chain incident because it is KEV-listed, associated with ransomware activity, and actively exploited in the wild.
• Inventory all repositories, CI pipelines, containers, build artifacts, developer workstations, and production deployments for affected @tanstack/* packages.
• Identify whether any affected package version was installed from npm during or after the malicious publishing window on 2026-05-11 19:20-19:26 UTC.
• Pin or upgrade to maintainer-confirmed clean package versions and regenerate lockfiles from a trusted dependency graph.
• Rotate secrets exposed to affected developer, CI, build, and runtime environments, prioritizing GitHub, npm, cloud, SSH, deployment, and artifact-registry credentials.
• Search historical CI logs, package-manager logs, endpoint telemetry, proxy logs, and EDR data for evidence of package installation and suspicious outbound activity following installation.
• Rebuild release artifacts and containers from clean dependencies rather than reusing artifacts produced during the exposure window.
• Add dependency allowlisting or denylisting controls to block known malicious versions once exact versions are identified from npm metadata or maintainer advisories.
• Harden internal GitHub Actions workflows that use pull_request_target, caches, and OIDC trusted publishing to prevent similar trust-boundary abuse.
• Complete remediation no later than the CISA KEV due date of 2026-06-10 for systems subject to KEV-driven remediation requirements.