Mini Shai-Hulud Strikes Again: How a Trusted npm Package With 150K Weekly Downloads Got Weaponized
Picture this: it's a Friday evening, your CI pipeline runs a routine npm install as part of a scheduled dependency refresh, and thirty seconds later a background script is quietly reading your environment variables, checking whether your GitHub token still works, and phoning home with the results. No alert fires. No antivirus flags it. The build finishes green. That's roughly what happened to teams pulling in @7nohe/openapi-react-query-codegen in late August 2026, and it's a scenario every SOC analyst and DevOps engineer should sit with for a minute.
This wasn't a sketchy typosquatted package from an unknown publisher. It was a legitimate, widely used code-generation tool with roughly 150,000 weekly downloads, signed with valid npm provenance, and shipped through an official GitHub Actions release pipeline. That combination — real package, real signature, real trust — is exactly what makes this incident worth breaking down in detail.
Table of Contents
- What Happened: The Timeline
- Understanding Mini Shai-Hulud and Why Provenance Wasn't Enough
- How the Attack Actually Worked
- What the Payload Did Once Installed
- Indicators of Compromise (IOCs)
- Detection: How to Check If You Were Exposed
- Prevention and Hardening Steps
- Expert Tips From the SOC Trenches
- Related Reading
- FAQ
- Conclusion
What Happened: The Timeline
On August 28, 2026, an attacker published ten malicious versions of @7nohe/openapi-react-query-codegen, a Node.js package that generates React Query (TanStack Query) hooks from OpenAPI specifications. The releases went out in two bursts roughly twenty minutes apart, and together they covered every actively maintained release line: the 0.5.x, 1.6.x, 2.2.x, and 3.0.x branches.
That last detail matters operationally. It means there was no single "safe" major version to pin to during the window — whichever line a project tracked, a poisoned release was waiting in it. Security researchers at Socket.dev were among the first to flag the activity, and follow-on analysis from firms including JFrog, Endor Labs, SafeDep, and Mend.io filled in additional technical detail over the following days.
Researchers have linked the campaign to the broader Shai-Hulud malware family — the same self-replicating npm worm lineage first documented in September 2025 and observed again in multiple waves since, including attacks tied to SAP-maintained packages and the AntV ecosystem. Some analysts have nicknamed this particular variant "Trinitite" based on a string found inside the obfuscated payload. Whether it's the same operators or copycats reusing leaked tooling is still an open question — researchers have noted overlapping techniques without confirming shared attribution.
Understanding Mini Shai-Hulud and Why Provenance Wasn't Enough
If you've been in this industry for more than a couple of years, you've probably told a junior developer at some point: "check that the package has provenance, check that it's signed, and you're good." This incident is a useful, uncomfortable reminder that provenance answers a narrower question than most people assume.
npm provenance proves that a specific automated workflow produced a specific artifact. It does not prove that the source code fed into that workflow was safe. In this case, the compromised releases were signed through GitHub Actions trusted publishing with valid attestations attached — meaning every automated check a developer might run would have shown a green checkmark. The problem lived one layer upstream, in how the publishing workflow decided what to build in the first place.
How the Attack Actually Worked
The root cause traces back to a flaw common in "comment-triggered" CI/CD automation. The project's release workflow could be triggered by a comment on a pull request. When triggered, it checked out the code from that pull request's source — including forks — and then published the result using the repository's trusted publishing identity.
The critical gap: the workflow did not verify that the person leaving the comment was a trusted maintainer or contributor. A threat actor using the GitHub account p00paboot opened a pull request from a fork containing malicious code, then left a comment that triggered the release job. The workflow dutifully checked out the fork's code, built it, signed it with the project's legitimate identity, and published it to npm — no compromised maintainer credentials required.
This is a textbook example of why "who has publish access" and "what can trigger a publish" are two different security questions, and both need answering.
What the Payload Did Once Installed
The malicious code activated during installation through two separate mechanisms, depending on the release: a manipulated binding.gyp build-configuration file that abused node-gyp's handling of native build steps, and — in later releases — an explicit preinstall script in package.json. Either path launched a heavily obfuscated JavaScript file that unpacked itself through multiple decoding layers before executing.
Once running, researchers observed the payload doing the following:
- Scanning local files, running processes, environment variables, and CI/CD variables for access tokens and credentials
- Querying cloud metadata services (AWS, Azure, GCP) commonly reachable from CI runners and cloud instances
- Validating whether stolen tokens actually worked before using them further
- Encrypting harvested data and staging it inside attacker-created public GitHub repositories
- Modifying GitHub Actions workflow files, likely to establish persistence or enable further automated abuse
- Adding background commands to AI coding-assistant configuration files on the infected machine
- Attempting to reuse stolen registry credentials to republish itself across additional npm packages, and — notably for this wave — RubyGems and PyPI as well
In short: this wasn't a smash-and-grab. It was designed to convert one compromised install into a foothold for lateral movement across a developer's entire toolchain — source control, package registries, cloud accounts, and CI infrastructure.
Indicators of Compromise (IOCs)
If your environment touched this package around the compromise window, the indicators below (compiled from public research by Socket.dev and follow-on analysis) are worth checking against your logs, lockfiles, and installed node_modules directories.
| Type | Indicator |
|---|---|
| Malicious package | @7nohe/openapi-react-query-codegen |
| Malicious versions | 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 pre-release hash-tagged builds) |
| Last known-good versions | 0.5.3, 1.6.2, 2.2.0, 3.0.2 |
| Threat actor GitHub account | p00paboot |
| Obfuscated payload file | 3FWCvzduYZg.js |
| Suspicious build file | binding.gyp (abused for command execution) |
| Related payload files | ai_init.js, ai_setup.sh |
| Persistence (Linux) | ~/.config/systemd/user/ entries referencing a "sysvinit-detect" naming pattern |
| Persistence (macOS) | ~/Library/LaunchAgents/ entry referencing the same naming pattern |
| Local artifact | /var/tmp/.shit (temporary staging path observed by researchers) |
Note: IPs, domains, and paths above are drawn from public vendor threat intelligence. Always validate against your own SIEM/EDR data before taking remediation action, and treat any host that installed an affected version as potentially compromised rather than merely "at risk."
Detection: How to Check If You Were Exposed
If you maintain Node.js projects, run through this checklist before assuming you're clear:
npm ls @7nohe/openapi-react-query-codegen --allThis walks your dependency tree (direct and transitive) for the package. If it returns nothing, you're likely not directly affected, but it's still worth checking lockfiles for historical references if you have long-lived branches or archived CI logs.
grep -r "7nohe/openapi-react-query-codegen" package-lock.json yarn.lock pnpm-lock.yamlUse this to catch cases where the package was pinned to a specific vulnerable version even if it's not currently installed locally — build logs and lockfile history can reveal exposure that a live npm ls won't.
If you find a match to one of the affected versions published between August 28's two release windows, treat the host or CI runner as potentially compromised — not just "needs an update." That means:
- Isolate the affected machine or CI runner from the network before doing anything else
- Preserve logs and any relevant forensic evidence before wiping
- Identify and neutralize persistence mechanisms (systemd user services, LaunchAgents, modified workflow files) before touching credentials
- Only then rotate exposed tokens — npm, GitHub, cloud provider, and any developer-tool API keys accessible from that machine
- Rebuild the environment from a known-clean image where practical rather than trying to fully "clean" a compromised host
That ordering — contain, preserve, neutralize persistence, then rotate — isn't arbitrary. Some variants in this malware family have been observed reacting when a monitored token suddenly returns an authentication error, which can trigger additional malicious activity before you've finished cleanup.
Prevention and Hardening Steps
This incident offers a genuinely actionable list of hardening steps, not just "be careful out there" advice:
- Audit comment-triggered CI/CD workflows. Any workflow that runs code based on issue or PR comments should verify commenter identity against a trusted-contributor list before doing anything with publish credentials.
- Don't treat provenance as a safety guarantee. Use it as one signal among several — pair it with version pinning, lockfile review, and dependency update monitoring.
- Pin dependencies and review diffs on updates. Avoid auto-merging dependency bumps for packages with install-time scripts without at least a cursory review.
- Restrict install script execution where possible. Tools and flags that disable arbitrary lifecycle scripts (preinstall/postinstall) during CI installs reduce blast radius significantly.
- Isolate CI runner credentials by scope. A compromised build shouldn't have standing access to your cloud infrastructure, source control admin functions, and package publishing all at once.
- Monitor for anomalous outbound connections from build environments, especially to code-hosting APIs, package registry token endpoints, and cloud metadata services during install steps.
Expert Tips From the SOC Trenches
A few practical notes worth internalizing beyond this specific incident:
First, "the package I use is popular and well-maintained" is not a security control. Popularity increases the blast radius of a compromise; it doesn't reduce the likelihood of one. If anything, popular packages are more attractive targets precisely because of their download counts.
Second, build automation deserves the same threat-modeling rigor as production infrastructure. Teams spend enormous effort locking down who can deploy to production, then leave CI/CD publishing workflows wired up to accept triggers from semi-public surfaces like PR comments. Attackers have noticed.
Third, this campaign's overlap with earlier Shai-Hulud waves is a reminder that once tooling for a supply-chain worm exists — especially if any part of it becomes open-sourced or leaked — it tends to resurface with new operators and cosmetic changes. Detection signatures built for "the original campaign" age quickly; behavioral detection (unusual install-time network activity, unexpected token validation calls) ages much better.
Related Cybersecurity Topics You Should Explore
- more vs less Linux Commands: The SOC Analyst's Log Review Guide
- JFrog Artifactory Hacked: Attackers Are Minting Admin Tokens
- tail -f Explained: The Linux Command That Beats Your SIEM's Delay
- Brave Browser Now Hides Your Real Email From Every Website
- D-Link Router Flaw Lets Hackers Steal Your Wi-Fi Password
- 'This Blog Has Been Locked' — How to Backup Blogger the Right Way
- cPanel Zero-Day Lets Hackers Seize Root Control of Your Server
- TP-Link Kasa Vulnerability Lets Hackers Hijack Your Smart Home Devices
- CVE-2026-16444: The TeamViewer Bug That Turns File Transfer Into RCE
- Hackers Weaponize Fake Resumes to Hijack PCs Silently
- 8.7M Airport Customers Breached — Are You One of Them?
- Claude Code Opus 5 Auto Mode Hijacked via Prompt Injection Attack
- A Broken Bluetooth Headset Exposed AliExpress's Secret Tracker
Frequently Asked Questions
Q: Is @7nohe/openapi-react-query-codegen still dangerous to install today?
A: The ten malicious versions were removed from the npm registry, and the maintainers redirected the latest tag back to a clean release. Always verify you're pulling a version published after the compromise window and confirm it against the maintainer's official security advisory before considering the package safe again.
Q: How is this different from the original Shai-Hulud worm from 2025?
A: The core objective — credential theft and self-propagation across package registries — is similar, and researchers have found overlapping tooling and techniques. This wave adds PyPI as a propagation target alongside npm and RubyGems, and uses a comment-triggered CI workflow abuse technique rather than relying solely on stolen maintainer credentials.
Q: Can npm provenance checks alone protect me from this kind of attack?
A: No. Provenance confirms which workflow built an artifact, not that the underlying source code is safe. This incident specifically demonstrates a case where provenance was valid but the release itself was malicious.
Q: What should CI/CD administrators do right now?
A: Review any release or publish workflow that can be triggered by PR comments, issue comments, or other externally-influenceable events, and add trusted-contributor verification before those triggers are allowed to run with publish-level permissions.
Q: Were enterprise environments confirmed to be affected?
A: Public research has documented the package's compromise and its download volume, but has not published a confirmed list of affected organizations. Any team using the package during the exposure window should assume potential impact and investigate rather than wait for formal notification.
Conclusion
The @7nohe/openapi-react-query-codegen compromise isn't remarkable because of some exotic new exploitation technique — it's remarkable because it exploited a trust assumption most teams don't even realize they're making. A signed, provenance-verified package from a legitimate, popular project turned out to be exactly as dangerous as an unsigned one, because the attacker found the one gap in the chain that verification doesn't cover: who's allowed to trigger a build.
If your team runs Node.js projects with automated dependency updates, take twenty minutes this week to audit your CI/CD publish triggers and check your lockfiles against the IOCs above. It's a small investment against a threat family that has now resurfaced multiple times in the past year and shows no sign of slowing down.
Got thoughts on this incident or questions about auditing your own CI/CD pipeline for similar exposure? Drop a comment below, and share this with your DevOps or SOC team if you think they'd want a heads-up.