CVE-2026-45321: Malware in 42 @tanstack/* packages exfiltrates cloud credentials, GitHub tokens, and SSH keys
On 2026-05-11, between approximately 19:20 and 19:26 UTC, 84 malicious versions across 42 @tanstack/* packages were published to the npm registry. The publishes were authenticated via the legitimate GitHub Actions OIDC trusted-publisher binding for TanStack/router, but the publish workflow itself was not modified. The attacker chained three known vulnerability classes — a pull_request_target "Pwn Request" misconfiguration, GitHub Actions cache poisoning across the fork↔base trust boundary, and runtime memory extraction of the OIDC token from the Actions runner process — to publish credential-stealing malware under a trusted identity. Each affected package received exactly two malicious versions, published a few minutes apart.
Security readout for executives and security teams
Plain-English summary
Attackers published 84 credential-stealing releases across 42 legitimate @tanstack packages during a six-minute window. Organizations that installed or executed those versions may have exposed cloud credentials, GitHub tokens, SSH keys, and other sensitive data. Because publication used TanStack’s trusted identity, ordinary publisher-trust checks were insufficient.
Executive priority
Immediate. Inventory affected dependencies, isolate impacted build environments, and begin credential rotation today. Treat confirmed installation or execution as a potential credential compromise, not merely a vulnerable dependency. Prioritize environments holding production cloud access, publishing permissions, source-code access, or SSH credentials.
Technical view
The attacker reportedly chained an unsafe pull_request_target workflow, cross-boundary GitHub Actions cache poisoning, and runtime extraction of an OIDC token. This enabled authenticated npm publication through the legitimate trusted-publisher binding without modifying the publishing workflow. Each affected package received two malicious versions.
Likely exposure
Exposure requires checking dependency manifests, lockfiles, package-manager caches, build records, containers, and deployed artifacts for the exact malicious versions. Systems where an affected release was installed or executed with access to developer, CI, cloud, GitHub, or SSH credentials warrant incident-response handling. The supplied affected list is incomplete, showing 20 of 42 packages.
Exploitation context
CISA KEV inclusion supports treating this as exploited in the wild. The source bundle describes an actual supply-chain compromise on May 11, 2026, rather than a theoretical weakness. Evidence does not establish which downstream organizations were compromised or whether every installation resulted in credential theft.
Researcher notes
The trusted OIDC publication identity does not prove package integrity because the runner token was reportedly extracted at runtime. Investigation should correlate package resolution timestamps with CI execution, credential access, and subsequent authentication events. Obtain the complete 42-package version list from the advisory; the supplied structured affected section contains only 20 packages.
Mitigation direction
Remove or replace every identified malicious package version using current TanStack guidance.
Rotate credentials accessible to affected developer, CI, build, and deployment environments.
Revoke exposed GitHub tokens, cloud credentials, SSH keys, and active sessions.
Rebuild affected artifacts from a verified clean dependency set and trusted environment.
Review TanStack and CISA guidance for additional packages or remediation updates.
Validation and detection
Search manifests and lockfiles for every malicious package and version listed by TanStack.
Inspect package caches, build logs, containers, and deployed artifacts for affected releases.
Review GitHub, cloud, SSH, and CI audit logs for suspicious credential use.
Confirm revoked credentials no longer authenticate and replacements are stored securely.
Verify rebuilt artifacts resolve only to versions TanStack identifies as clean.
The source record changed after analysis: Material source record changed after analysis.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-506: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references authentication or credential exposure, so valid-account and credential-access review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
Exploitation: activeAutomatable: noTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-506 · source CWE mapping
Embedded Malicious Code
Embedded Malicious Code represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.