@7nohe/openapi-react-query-codegen Compromised Through an Exposed npm Publishing Workflow

On August 28, 2026, an external GitHub user exploited the release workflow for @7nohe/openapi-react-query-codegen and published ten malicious npm versions. The affected releases execute attacker supplied code during installation. The eight stable releases used a malicious binding.gyp path, an explicit preinstall hook, or both. Direct execution of the payload from version 3.0.4 attempted to retrieve GitHub credentials, contacted the GitHub API, and probed the Google Cloud metadata hostname.

The attacker did not need a maintainer npm password or a long lived npm token. The repository accepted an npm publish comment from any pull request participant, checked out that pull request, installed its dependencies, and published packages with a GitHub Actions OIDC identity.

StepSecurity reproduced the installation behavior on isolated GitHub hosted runners under Harden-Runner.

The Compromised Package

The eight malicious stable versions appeared between 20:00:43 and 20:20:53 UTC. Version 0.5.4 grew from 41,621 bytes in 0.5.3 to 5,658,449 bytes. The other malicious stable artifacts ranged from 4.46 MB to 6.53 MB. Version 3.0.4 added this lifecycle hook:

"preinstall": "node 3FWCvzduYZg.js"

The 3FWCvzduYZg.js file is 6,384,601 bytes. Its SHA256 digest is:

b24d121667f21f492cb9db34fbfd515d5922a8dd30b9c45215c7220abbb10ca8

StepSecurity OSS AI Package Analyst assigned version 3.0.4 a security score of 0, marked its risk as critical, and returned a rejected recommendation. That hosted model identified XOR decoded code passed to the JavaScript Function constructor, the malicious preinstall hook, and an obfuscated binding.gyp execution path. This verdict is independent static analysis. The runner observations below are direct behavioral evidence.

How the Attack Works

An external comment reached a trusted publisher

The repository release workflow listened for issue_comment events. It required only that the comment belonged to a pull request and that its body exactly matched npm publish. The workflow did not verify the commenter's repository role or association.

The workflow then checked out the pull request head, ran pnpm install, and published through npm Trusted Publishing with id-token: write. This placed untrusted pull request code inside a privileged release job.

GitHub user p00paboot opened pull requests #215 and #216, then posted the trigger comment. The related workflow runs successfully reached their publish steps. npm registry timestamps followed within seconds.

The stable releases execute during installation

The four stable versions detonated so far, 1.6.3, 2.2.1, 3.0.3, and 3.0.4, all caused curl to contact GitHub and release-assets.githubusercontent.com during installation. Harden-Runner then observed an executable named bun under a temporary directory with the prefix /tmp/trinnyyyy-. Registry metadata confirms that newly identified versions 0.5.5, 1.6.4, and 2.2.2 contain the same preinstall command. Version 0.5.4 was published in the same attacker controlled run and expanded by more than 5.6 MB.

Version 3.0.4 also contains a malicious binding.gyp condition. The condition traverses Python objects to reach os.system() and decodes to this command:

node 3FWCvzduYZg.js

This gives the attacker another path to the same payload when node-gyp evaluates the file.

Runtime Validation with StepSecurity Harden-Runner

The Harden-Runner analysis run tested every affected version at installation time and import time. It also executed the 3.0.4 payload directly inside the GitHub hosted runner with CI marker variables removed.

The direct payload job produced this sequence:

1. Node executed 3FWCvzduYZg.js.
2. The payload spawned curl and downloaded Bun from GitHub release infrastructure.
3. The new executable ran from /tmp/trinnyyyy-doj0LR/bun.
4. The staged Bun code ran gh auth token.
5. It ran git credential-manager github list --no-ui.
6. It checked for ssh and scp, enumerated running processes, and invoked a shell with a temporary updater.py path.

The job specific network view ties the observed destinations to the payload processes.

Indicators of Compromise

Package versions

@7nohe/openapi-react-query-codegen@0.5.4
@7nohe/openapi-react-query-codegen@0.5.5
@7nohe/openapi-react-query-codegen@1.6.3
@7nohe/openapi-react-query-codegen@1.6.4
@7nohe/openapi-react-query-codegen@2.2.1
@7nohe/openapi-react-query-codegen@2.2.2
@7nohe/openapi-react-query-codegen@3.0.3
@7nohe/openapi-react-query-codegen@3.0.4
@7nohe/openapi-react-query-codegen@0.0.0-365d4eb738d3146583431948d3ba6e27a32556be
@7nohe/openapi-react-query-codegen@0.0.0-ec7876d6c917dad516ba69bbfafc948b834bf0ab

Files and artifacts

3FWCvzduYZg.js
binding.gyp
is_it_this_simple.js
nu.js
/tmp/trinnyyyy-*/bun
/tmp/*.js
/tmp/*/updater.py

Registry hashes

Am I Affected?

CI/CD pipelines

Search workflow logs, dependency caches, lockfiles, SBOMs, and build provenance for the affected versions. Review your Harden-Runner organization baseline for new Bun execution and unexpected GitHub API traffic during dependency installation.

Developer machines

Search developer workstations for the payload filename, the temporary trinnyyyy directories, and unexpected Bun executables created at the time of installation. Dev Machine Guard suspicious file rules can help detect these artifacts across managed developer endpoints.

Recovery Steps

1. Stop builds and isolate systems that installed an affected version with lifecycle scripts enabled.
2. Use a separate clean system to rotate npm, GitHub, cloud, CI/CD, SSH, signing, and deployment credentials that the affected process could access.
3. Invalidate active sessions and review audit logs for unusual repository access, package publication, cloud API calls, or newly created credentials.
4. Remove affected dependency caches and discard artifacts built on exposed runners.
5. Pin the appropriate release line to known clean version 0.5.3, 1.6.2, 2.2.0, or 3.0.2.
6. Rebuild from a clean environment with a reviewed lockfile.

How StepSecurity Protects Against This

Harden-Runner records process and network activity in GitHub Actions. Its runtime evidence exposed the Bun download and the temporary executable in this incident. In block mode, Harden-Runner permits only endpoints on the job's configured allowlist.

Dev Machine Guard extends compromised package detection to developer workstations, where npm lifecycle malware can access long lived credentials and local source code. Suspicious file rules can identify the payload name and temporary executable pattern associated with this incident.

Acknowledgment

Charlie Eriksen reported the malicious releases in GitHub issue #217.

References

• npm package page for version 3.0.4
• GitHub issue #217
• Pull request #215
• Pull request #216
• First malicious release workflow run
• Second malicious release workflow run
• Harden-Runner detonation run
• Direct payload network evidence
• StepSecurity OSS Security Feed