GitHub Actions comment trigger published malicious openapi-react-query-codegen

A GitHub account created for the purpose spent twenty minutes on the evening of August 28, 2026 turning a convenience feature in one npm project's release pipeline into a package-publishing machine. Ten malicious versions of @7nohe/openapi-react-query-codegen went out during that window, each of them built, signed, and provenance-attested by the maintainer's own automation. The repository itself was never touched. The package generates React Query hooks from an OpenAPI schema, the kind of code-generation step that lives in a front-end project's devDependencies rather than its production bundle, and Socket and Mend both put it at roughly 150,000 downloads a week.

The way in was a GitHub Actions trigger the project had carried since 2024. Its release workflow listened for issue_comment events: comment npm publish on any pull request and the job would fetch that pull request's head, check it out, run pnpm install, and publish a 0.0.0-<sha> prerelease. The job never checked who was commenting. In March 2026 the project moved that same workflow to npm trusted publishing, which meant it also held id-token: write and could exchange a GitHub OIDC assertion for a real npm token. An account named p00paboot, using the address [email protected], opened pull requests #215 and #216 and pushed a one-line change to package.json in each: first a preinstall that piped Bun's installer into bash and ran a script called is_it_this_simple.js, then nineteen minutes later node nu.js. Neither script shipped in the published tarball, because neither needed to. The point was to execute inside the runner during pnpm install, in a job that could ask GitHub for a publishing credential.

npm's publication log shows what followed. At 20:00:43 UTC 0.5.4 appeared, then 1.6.3 five seconds later, 2.2.1 at 20:00:53, and 3.0.3 at 20:02:08, four stable releases spanning every maintained line of the package, the first three landing seconds before the workflow reached its own prerelease step. The second comment produced the same pattern at 20:19: 3.0.4, 1.6.4, 2.2.2, and 0.5.5. All eight carried an 828-byte binding.gyp and a single-line loader named 3FWCvzduYZg.js running between 4.4 MB and 6.4 MB. The binding.gyp is the more interesting half. Its conditions block holds a Python expression that walks ().__class__.__base__.__subclasses__() to reach os.system, with every identifier written as \U000000xx escapes so no readable string appears anywhere in the file, ending in node 3FWCvzduYZg.js. npm hands any package containing a binding.gyp to node-gyp rebuild, and that path is not covered by --ignore-scripts. The four wave-1 versions carried no install hook at all and relied on it entirely; the wave-2 four added "preinstall": "node 3FWCvzduYZg.js" as a fallback. As Mend's Alina Podoba noted, detection has to match on the files, not just on the hooks.

The loader is an array of integers XORed with the byte 229, yielding JavaScript that decrypts an AES-128-GCM blob with a hardcoded key, IV, and tag, unpacking a roughly 800 KB obfuscated bundle that downloads Bun 1.4.0 into a temporary directory prefixed trinnyyyy- and re-executes under it. Researchers at Socket, SafeDep, StepSecurity, and Mend all identified the result as the Mini Shai-Hulud toolkit seen in the SAP CAP compromise in April and the @antv mass compromise in May. Socket described it reading AWS IMDSv2, Azure and Google Cloud metadata, HashiCorp Vault, Kubernetes service account tokens, registry credentials for npm, PyPI, RubyGems and JFrog, gh auth token output, and the configuration files of a long list of AI coding assistants, then creating public GitHub repositories to hold encrypted exfiltrated data and installing a token monitor that polls once a minute under a LaunchAgent or systemd unit named sysvinit-detect-fash. Charlie Eriksen filed issue #217 at 20:18:44 UTC listing four bad versions, about a minute before the second wave began. Maintainer Daiki Urata pushed a fix at 22:50:03 that deleted the issue_comment trigger outright, dropped issues: write, disabled credential persistence in the checkout, and pinned installs to the lockfile; releases now run on tag push only. The OpenSSF malicious-packages feed published MAL-2026-15494 at 22:59:24, Mend recorded a GHSA at 23:51 scored CVSS 9.6, and npm removed all ten versions at about 04:11 UTC on August 29, restoring the latest tag to 3.0.2. Every malicious artifact in the incident carries valid provenance signed by npm's own infrastructure and bound to the project's real release.yml, because the workflow that produced them was, in the strictest sense, the legitimate one.