A Worm That Outlived Its Own Arrests
In late August 2026, Australian authorities arrested individuals allegedly connected to TeamPCP, the group researchers had linked to earlier waves of the self-propagating npm worm known as Shai-Hulud. About a day later, JFrog Security Research detected a new wave using nearly identical tooling under a new campaign name, Trinitite, describing itself in its own code as "Sponsored by Preview 2 Effects." Same kit, new RSA keys, and evidently a new operator willing to pick up where the arrested group left off almost immediately.
The target this time was @7nohe/openapi-react-query-codegen, a code-generation package built on top of TanStack Query that pulls more than 150,000 weekly downloads. Ten versions carried the payload, including two prerelease builds and eight stable releases, all published within roughly twenty minutes of each other. That speed is itself the point: the worm's automated publishing pipeline does not wait for a maintainer's review cycle, because it does not need one.
The Vulnerability Was a Broken Trust Assumption, Not a Code Bug
The entry point was not a traditional software vulnerability at all. The package's release workflow treated any pull request comment that said exactly npm publish as a valid release trigger, without verifying that the commenter was actually an authorized maintainer. A GitHub account named p00paboot opened pull requests and posted that trigger phrase, and GitHub Actions dutifully published new versions using the repository's OIDC publishing credentials. No credentials were stolen to start the chain. The automation simply trusted the wrong signal.
This is the pattern defenders keep underestimating in CI/CD security: the weakest link is rarely the cryptography, it is the authorization logic wired into automation that nobody has stress-tested against an adversarial actor. Plenty of open-source maintainers wire up comment-to-trigger release workflows for convenience, assuming only trusted contributors will ever leave that comment. Trinitite is proof that assumption does not survive contact with an attacker actively scanning GitHub for exactly this kind of workflow.
What the Payload Actually Does
Once installed, the malware hides inside a binding.gyp file using Unicode-escaped Python that runs even when a security tool has disabled npm lifecycle scripts, a bypass technique that defeats one of the more common supply-chain mitigations teams have adopted over the past two years. From there it harvests GitHub, npm, PyPI, and RubyGems tokens, cloud provider credentials, Vault secrets, and Kubernetes configuration, compressing and encrypting everything before committing it to a public GitHub repository under the victim's own hijacked token.
The self-propagation is what earns it the worm label. According to JFrog's research, "the worm also includes logic to republish packages for which it obtains npm publishing rights," exchanging stolen OIDC tokens for npm credentials and using them to infect the next package automatically. It also carries a destructive fallback: if a monitored GitHub token gets revoked, meaning the victim noticed and responded, the malware can wipe the user's home directory and Documents folder on Linux and macOS systems, turning incident response into data loss.
The Same Playbook Has Hit Mistral, SAP, and Beyond
Trinitite is a variant of a much longer-running campaign. Earlier waves of Shai-Hulud style worms compromised packages tied to SAP in April 2026, and separate reporting on the broader mini Shai-Hulud campaign put the count at more than 160 affected packages, including ones associated with Mistral's ecosystem, before the TanStack-adjacent package was hit in August. Each wave reuses the same core techniques: a broken authorization assumption in an automated publish workflow, credential harvesting disguised inside an obfuscated loader, and self-propagation through stolen publishing rights.
The consistency across waves is the useful signal for defenders. Treating each wave as one recurring attack pattern, refined and relaunched every few months against a new set of high-download packages, makes the mitigation reusable too. Any organization that hardened its CI/CD pipeline after the SAP-adjacent wave in April should already have been resistant to Trinitite in August, provided the hardening addressed the underlying authorization gap rather than just blocking the specific package versions involved that time.
Why Disrupting One Crew Does Not Shrink the Threat
The one-day gap between TeamPCP's arrests and Trinitite's appearance is the detail worth sitting with. Law enforcement action against a specific criminal group is a genuine win, but it does not remove the toolkit, the technique, or the market incentive that made the original campaign profitable. Whoever picked up Trinitite had the source, the infrastructure playbook, and evidently the willingness to keep running it within about 24 hours, which suggests either a second operator with access to the same tooling or a rapid handoff that arrests alone cannot interrupt.
For engineering leaders, the actionable response is not waiting for the next arrest to feel safe. It is auditing every comment-triggers-deploy or comment-triggers-publish automation in your own CI/CD pipelines, because that exact pattern is what let a stranger publish code as a trusted maintainer. Pin dependency versions, require signed commits from verified maintainers before any publish workflow fires, and assume that whatever technique compromised a 150,000-download package this month will be pointed at a package in your own dependency tree next.
