Trinitite worm hits npm TanStack Query codegen package
A self-spreading npm worm researchers call Trinitite pushed ten malicious builds of @7nohe/openapi-react-query-codegen, a third-party code generator for TanStack Query, on 28 August. The maintainer's GitHub advisory rates it critical at CVSS 9.6 with no CVE assigned. Pin back to 3.0.2 and treat any CI runner that installed it as exposed.

A self-spreading npm worm that researchers are calling Trinitite pushed poisoned builds of a popular code generator on 28 August, and the package is a community tool for TanStack Query, not one of TanStack's own. The maintainer's GitHub security advisory rates the incident critical at CVSS 9.6 and carries no CVE. It says ten tainted versions of @7nohe/openapi-react-query-codegen were published through a compromised release workflow, so anyone who installed an affected version, "including transitively or in CI," ran "attacker-controlled code with the privileges of the installing process." If your build pulled the package in the last few days, treat this as an exposure to confirm, not a bug to patch, and pin back to 3.0.2.
Which versions to pull
The advisory lists eight tainted stable releases (0.5.4, 0.5.5, 1.6.3, 1.6.4, 2.2.1, 2.2.2, 3.0.3, 3.0.4) plus two 0.0.0 prereleases, all pushed on 28 August. The last clean stable build is 3.0.2, and the older 0.5.3, 1.6.2, and 2.2.0 are also safe. The maintainer traced the break to a misconfigured GitHub Actions workflow that let an unauthorized trigger cut releases, and has since moved publishing to a tag-push flow and written up the postmortem in issue 217. That closes the specific hole that was used. It is not a clean bill of health for everything already in the registry.
What the worm is after
Per JFrog's writeup, Trinitite is a new wave of the Shai-Hulud worm: it hunts credentials across GitHub, npm, PyPI, RubyGems, cloud providers, and Kubernetes, scrapes CI-runner memory for secrets, and republishes packages under stolen tokens to keep spreading. The operative fact for defenders is the advisory's impact line, not the payload's plumbing: install-time code execution wherever the package landed, transitive dependencies and CI jobs included. That is why a lockfile bump alone does not close this out.
Not TanStack, and not a numbered CVE
Two things are worth getting right, because the wires keep blurring both. First, this is third-party tooling: @7nohe/openapi-react-query-codegen generates React Query hooks from an OpenAPI spec, and it is not shipped by the TanStack team. It is a different target from the earlier Shai-Hulud wave that hit official @tanstack packages. Second, there is no CVE. The record here is the repository advisory GHSA-9pvf-vcx3-x239; the global github.com/advisories mirror still returns 404, and any "CVE-2026" number circulating for this is not an identifier to track.
What is still unsettled
Attribution is open. JFrog declines to pin it on the crew behind earlier Shai-Hulud activity, writing that it "could be leftover access. Could be someone else wearing the cat mask. The payload does not settle that." The blast radius is fuzzy too: JFrog puts the package in the "150K+ weekly download range," while OX Security's account counts 128,223 weekly downloads, and the labs' technical descriptions of the loader differ in places. Treat any single exposure figure as an estimate, not a headcount.
Do this in order
Isolate first, then rotate. The advice that lines up across the advisory, JFrog, and Aikido is to quarantine any machine or runner that executed an affected version before you touch tokens, because this worm specifically watches for credential rotation. Pin to 3.0.2 (or 0.5.3, 1.6.2, 2.2.0), rebuild from a clean environment, then rotate GitHub, npm, and cloud secrets. It is the same supply-chain discipline the recent poisoned Rust crates and the OwnCloud and Artifactory flaws on CISA's KEV list point back to, and the same reason letting an agent auto-run untrusted code, as in the Claude Code auto-mode prompt-injection case, earns the same caution: pin dependencies, gate CI on provenance, and assume install scripts run as you.
The takeaway
Move your lockfile to a clean version now and audit every CI job that installed the package since 28 August; the maintainer has shut the workflow hole, but with attribution unresolved and a live worm republishing under stolen tokens, the safe working assumption is that any runner that touched a bad version already leaked its secrets.
Cyberpresso: daily cyber & AI brief
Free daily newsletter, read in 5 minutes.
Subscribe free