The Provenance Was Valid. The Workflow Let Anyone Publish the Malware.
The package was signed by the right automation. That did not make the release legitimate.
On 28 August 2026, an external GitHub user abused the release workflow for @7nohe/openapi-react-query-codegen to publish ten malicious npm versions. The packages ran attacker-controlled code during installation, targeted developer and cloud credentials, and carried valid npm provenance generated by the project’s own GitHub Actions workflow.
That last detail is the important one. This was not a forged package pretending to come from a trusted pipeline. The trusted pipeline really did publish it. The failure was that an untrusted pull request participant could tell that pipeline what to release.
Ten malicious releases in twenty minutes
The affected versions were:
0.5.4and0.5.51.6.3and1.6.42.2.1and2.2.23.0.3and3.0.40.0.0-365d4eb738d3146583431948d3ba6e27a32556be0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab
StepSecurity says the eight stable releases appeared between 20:00:43 and 20:20:53 UTC on 28 August. The attacker spread the releases across every maintained version line, increasing the chance that automated dependency updates or ordinary installation commands would select a compromised build.
At the time of the initial disclosures, npm’s latest tag still resolved to malicious version 3.0.4. The registry has since removed the malicious releases and restored clean version 3.0.2 as the current release. The package page currently reports roughly 155,000 weekly downloads across all versions. That figure describes the package’s reach, not the number of confirmed compromised installations.
A comment crossed the release boundary
The vulnerable GitHub Actions workflow listened for comments on pull requests. If the comment body matched npm publish, the job checked out the pull request’s code, installed its dependencies and published the resulting package.
What the workflow did not do was verify that the person posting the comment was a maintainer or another authorised repository member.
An external account could therefore open a pull request from a fork, add attacker-controlled code and post the trigger phrase. The privileged workflow then ran that untrusted code with id-token: write and used npm Trusted Publishing to issue the release.
The resulting provenance was cryptographically valid. It correctly said that GitHub Actions and the project’s release workflow had published the package. It could not say whether the person who caused that workflow to run was authorised to do so.
That distinction matters far beyond this package. Provenance answers where an artifact came from. It does not automatically prove that the event that initiated the build was trustworthy, that the source selected by the workflow was reviewed, or that the workflow enforced an approval boundary.
The malware ran during installation
The stable malicious packages used two execution paths. Some placed an obfuscated command in binding.gyp, which could be evaluated by node-gyp during installation. Later versions also declared an explicit preinstall hook that ran a large obfuscated JavaScript file named 3FWCvzduYZg.js.
StepSecurity reproduced the behaviour in isolated GitHub-hosted runners. Its telemetry showed the package downloading Bun from GitHub release infrastructure, running the executable from a temporary directory beginning with /tmp/trinnyyyy-, querying GitHub authentication material and checking additional credential sources.
Socket’s analysis found a second-stage payload that targeted cloud credentials, package-registry credentials, GitHub Actions secrets and AI-agent configuration. Endor Labs reported self-propagation logic spanning npm, RubyGems and PyPI, which makes the incident more than a one-package compromise. Credentials taken from one developer environment or CI runner could provide the material needed to seed another ecosystem.
There is no need to inflate the claim. The public evidence establishes malicious package publication, installation-time execution, credential discovery and propagation capability. It does not establish that every weekly download was a malicious version or that every exposed credential was successfully exfiltrated and reused.
What defenders should do now
Organisations should search lockfiles, dependency inventories, CI logs, build caches and software bills of materials for all ten affected versions. Finding one should be treated as possible code execution in the context that performed the installation.
The response should include:
- Stop affected builds and isolate developer systems or runners that installed a malicious version with lifecycle scripts enabled.
- Rotate GitHub, npm, cloud, CI/CD, SSH, signing and deployment credentials that the process could access. Perform the rotation from a known-clean system.
- Invalidate active sessions and review audit logs for unexpected repository access, package publication, cloud API calls and new credentials.
- Remove contaminated dependency caches and discard artifacts produced by exposed runners.
- Rebuild from a clean environment using a reviewed lockfile.
- Pin the relevant release line to a known-clean version:
0.5.3,1.6.2,2.2.0or3.0.2.
Useful indicators include 3FWCvzduYZg.js, is_it_this_simple.js, nu.js, temporary trinnyyyy directories, unexpected Bun execution during package installation and unusual GitHub API activity from build jobs.
Provenance needs an authorisation model
Trusted publishing removes long-lived registry tokens from release pipelines, which is a real security improvement. This incident does not invalidate that model. It shows the boundary that the model does not cover by itself.
A secure publishing workflow must validate the actor, the source ref and the reviewed commit before it requests a publishing identity. Comment-triggered jobs should check the commenter’s repository association, restrict which branches or commits may be released and require an environment approval or another maintainer-controlled gate before publication.
Defenders also need to monitor the build system as a production security boundary. A valid attestation can help trace an incident back to the responsible workflow. It should not be treated as an independent verdict that the workflow made a good decision.
The provenance on these packages was not fake. It faithfully documented a trusted automation path that an outsider was allowed to drive.
Sources
- StepSecurity: @7nohe/openapi-react-query-codegen Compromised Through an Exposed npm Publishing Workflow, published 28 August 2026. No publication time was provided.
- Socket: OpenAPI React Query Codegen Compromised in Mini Shai-Hulud npm Supply Chain Attack, published 28 August 2026. No publication time was provided.
- Endor Labs: Mini Shai-Hulud worm hits openapi-react-query-codegen, published and updated 28 August 2026. No publication times were provided.
- npm package page for @7nohe/openapi-react-query-codegen, checked 30 August 2026.
- GitHub releases for 7nohe/openapi-react-query-codegen, checked 30 August 2026.
