Notifications
Clear all
Topic starter
06/09/2026 6:21 pm
TL;DR: An exposed npm publishing workflow for @7nohe/openapi-react-query-codegen let an external GitHub user ship ten malicious package versions that executed attacker code during installation and probed GitHub and cloud metadata endpoints, according to StepSecurity. The incident shows that trusted publishing, without comment authorization and install-time isolation, can still become a credential-theft path.
NHIMG editorial — based on content published by StepSecurity: Compromised Through an Exposed npm Publishing Workflow
By the numbers:
- The eight malicious stable versions appeared between 20:00:43 and 20:20:53 UTC.
Questions worth separating out
Q: What breaks when an npm release workflow can be triggered by untrusted pull request activity?
A: The release boundary breaks because an attacker can convert a contribution path into a publish path.
Q: Why do malicious package install scripts create such a large identity risk?
A: Because install scripts run inside environments that often already contain GitHub tokens, cloud credentials, signing material, and cached secrets.
Q: What do security teams get wrong about supply chain package review?
A: They often review only source code and ignore lifecycle hooks, native build files, and payload size changes.
Practitioner guidance
- Lock release workflows to authorized actors Require explicit repository role checks and protected-review approval before any publish step can run.
- Isolate install-time execution Run dependency installation in environments that cannot reach production credentials, signing keys, or cloud metadata.
- Audit for exposed release identities Review GitHub Actions OIDC usage, npm provenance, and repository release permissions for workflows that can publish from pull request context.
What's in the full analysis
StepSecurity's full blog covers the operational detail this post intentionally leaves for the source:
- The exact release workflow logic that let a pull request comment trigger publishing through GitHub Actions OIDC.
- The installation-time process evidence, including Bun execution, GitHub API contact, and cloud metadata probing.
- The affected package versions, hashes, and indicators of compromise needed for environment-wide hunting.
- The recovery steps for isolating systems, rotating credentials, and rebuilding from a clean lockfile.
👉 Read StepSecurity's analysis of the exposed npm publishing workflow compromise →
Exposed npm release workflows: what CI teams need to change now?
Explore further
06/09/2026 6:21 pm
Workflow identity abuse is now a supply chain problem, not just a CI misconfiguration. When a release job can be triggered by an untrusted pull request comment and still publish with trusted publishing credentials, the workflow identity becomes the security boundary. That creates a privileged execution path that looks legitimate to automation but is operationally indistinguishable from abuse. Practitioners should treat build workflows as governed identities with explicit authorization, audit, and revocation controls.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- The same research found that DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
A question worth separating out:
Q: How should teams respond when a package publication workflow is compromised?
A: Contain the environments that installed the affected versions, then rotate any credentials those environments could access from a clean system. Rebuild from a known-good lockfile, invalidate active sessions, and review logs for publication events, GitHub API calls, cloud metadata access, and unexpected build artefacts.
👉 Read our full editorial: Exposed npm release workflows turn packages into CI credential theft paths
