A major security incident has struck the npm ecosystem: the package @7nohe/openapi-react-query-codegen, downloaded over 150,000 times per week, is being used as a channel for a credential-stealing supply-chain worm dubbed “Trinitite.” The malicious versions are capable of executing upon dependency installation or through crafted build configurations, putting both developer workstations and CI/CD systems at risk.
What Went Wrong
Researchers from JFrog discovered the attack after finding that around ten releases published over twenty minutes on August 28 contained malicious payloads. The attackers exploited the package’s release workflow rather than npm itself. Specifically, any pull request comment matching a particular trigger could initiate a GitHub Actions workflow via OpenID Connect (OIDC), allowing the attacker to gain a trusted publishing token without maintainer oversight. While the release’s provenance shows the publishing process was legitimate, it does not guarantee that the code itself is safe.
The compromised versions included two pre-releases that had only parts of the malware, and eight stable versions that carried the full worm. The malicious behavior made use of two techniques: some versions added a weaponized binding.gyp file; others included a preinstall hook. These tactics allow the malware to bypass common defenses, since node-gyp can trigger binding.gyp processing even when lifecycle scripts are skipped.
What the Worm Does & How to Recover
Named a new wave of the Mini Shai-Hulud attacks, Trinitite quietly harvests credentials tied to GitHub, npm, PyPI, RubyGems, cloud platforms, HashiCorp Vault, and Kubernetes. It also targets CI secrets and metadata in environments used for AI development. Harvested data is encrypted and committed to public repositories using victims’ GitHub tokens, then used to push altered packages and introduce workflows that collect even more secrets.
To evade detection, Trinitite includes persistence modules for Linux and macOS, and monitors GitHub token status. If it detects that a token has been revoked, it may execute destructive routines. For affected developers and organizations, containment must happen before rotating credentials. They should isolate compromised machines or runners, disable affected user services, clean up temporary and persistence files, and rebuild lockfiles. Only after full cleanup should credential rotations occur.
Indicators of compromise include the package name, specific malicious version numbers (such as 0.5.4, 1.6.3, 2.2.2, 3.0.4), and a set of known safe versions (like 0.5.3, 1.6.2, 2.2.0, 3.0.2). Files involved include binding.gyp, package.json, and scripts such as dog.c among others. Persistence artifacts on Linux and macOS have been identified in numerous paths, including systemd services and LaunchAgents.
This incident follows earlier supply-chain attacks under the Shai-Hulud umbrella, where trusted packages were used to distribute malware across software development pipelines. What sets Trinitite apart is its ability to self-propagate by abusing release workflows and the publishing system, turning what should be a trusted dependency into a weapon.
What to Watch For
- Pull request comments that trigger automated release workflows in packages you depend on.
- Unexpected use of
binding.gyporpreinstallhooks in new versions. - Files or services in unusual paths created post install (like temporary directories for Bun, systemd/user services, LaunchAgents).
Finally, even trusted provenance signatures or release job histories should be treated with caution. They are signals of process, not guarantees of integrity.
This breach shows how rapidly supply-chain exploits can escalate. As developers and organizations increasingly rely on open-source dependencies and automated tooling, resilient workflows, rigorous maintainer practices, and credential hygiene become essential shields.
Analysis: Trinitite marks a chilling evolution in supply-chain threats. By compromising release pipelines themselves—not just code or registry vulnerabilities—attackers can inject malicious payloads deeply and automatically. This raises the stakes for maintainers: controlling who can trigger releases, auditing automated workflows, and limiting access privileges are no longer optional. For builders of dev tools and organizations relying on open source, it’s time to assume breach in your dependency tree—and design defenses accordingly.
