Exposed npm release workflows turn packages into CI credential theft paths

At a glance

What this is: StepSecurity found that an exposed npm publishing workflow let an external GitHub user publish ten malicious package versions that ran attacker code during installation.

Why it matters: This matters because CI/CD release jobs can turn into identity abuse paths when untrusted pull request code is published under a trusted workflow identity and then runs with accessible credentials.

By the numbers:

• The eight malicious stable versions appeared between 20:00:43 and 20:20:53 UTC.

👉 Read StepSecurity's analysis of the exposed npm publishing workflow compromise

Context

Exposed release workflows create a governance gap when untrusted contribution paths can reach publishing privileges. In this case, the problem is not only malicious package content, but the identity and privilege boundary inside CI/CD, where a GitHub Actions OIDC identity was used to publish code that had been checked out from a pull request. That is a supply chain control failure with a clear identity dimension.

For IAM, PAM, and NHI teams, the lesson is that build-time and install-time identities must be treated as distinct security subjects with separate controls. A trusted publishing flow can still be compromised if repository comments, pull request state, and package publication are not bound to strong authorization checks and runtime containment. That pattern is now routine enough to require explicit governance, not ad hoc review.

Key questions

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. If the workflow accepts trigger text without checking repository role, review state, and actor authorization, it can publish attacker-controlled code under a trusted identity. That is a control failure in release governance, not a problem with npm alone.

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. A package that executes at install time can probe those assets before many controls notice. The risk is highest in CI/CD and developer workstations where privileged access is normal and logging is inconsistent.

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. That misses the actual execution surface. Review should include install-time behaviour, binding.gyp paths, and any obfuscated or oversized artefacts that can hide code execution during dependency installation.

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.

Technical breakdown

Trusted publishing can still be subverted through workflow identity abuse

GitHub Actions trusted publishing binds package release activity to an OIDC-backed workflow identity, but that identity is only as safe as the workflow logic that gates it. In this incident, the release job accepted an issue_comment trigger from a pull request participant, checked out attacker-controlled code, and then published with id-token: write. That means the attacker never needed a maintainer npm password or a long-lived npm token. The failure sits in the authorization layer around the workflow, not in npm itself.

Practical implication: bind release jobs to explicit role checks and reviewer state before any publish step can execute.

Install scripts turn package consumption into code execution

npm lifecycle hooks such as preinstall allow package authors to run code at install time. That is powerful for legitimate build steps, but it becomes a direct execution channel when a malicious package reaches consumers. StepSecurity observed attacker-supplied code retrieving credentials, contacting the GitHub API, probing cloud metadata, and downloading Bun during installation. The risk is not just dependency compromise, but immediate execution inside developer and CI environments that already hold secrets and deployment access.

Practical implication: treat package installation as execution, not passive download, and isolate environments accordingly.

Obfuscated payloads and native build paths widen the detection gap

The malicious releases used multiple execution routes, including a preinstall hook and a binding.gyp path that resolved to a node-gyp execution flow. That matters because defenders often inspect only obvious script hooks and overlook native build metadata or obfuscated JavaScript files. StepSecurity also noted large payload sizes and XOR-decoded code passed into the JavaScript Function constructor, which are strong indicators of concealment. The technical pattern is layered execution intended to survive basic package review and simple static checks.

Practical implication: inspect lifecycle hooks, native build files, and unusually large package deltas together, not in isolation.

Threat narrative

Attacker objective: The attacker aimed to turn a trusted package release path into a credential-harvesting and code-execution channel inside downstream developer and CI environments.

1. Entry occurred when an external GitHub user triggered the repository's release workflow through a pull request comment that matched the publish command.
2. Credential access followed as the malicious package code attempted to retrieve GitHub credentials and probe cloud metadata during installation.
3. Escalation and impact came from publishing ten malicious npm versions that executed attacker code in consumer environments and could expose accessible secrets.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Install-time execution is the real blast radius for compromised packages. The important issue is not simply that a malicious package exists, but that npm lifecycle scripts execute in environments that already contain tokens, caches, and source access. This is why package security overlaps directly with NHI governance: installation scripts can reach cloud, GitHub, and deployment credentials faster than many teams can detect. The field needs controls that assume install-time code is hostile until proven otherwise.

Native build paths and payload inflation create a detection blind spot. Large artefact deltas, binding.gyp execution paths, and obfuscated payloads are not implementation noise. They are concealment techniques that evade review patterns built around source-only inspection. Security teams should treat package size spikes and native build metadata as escalation signals, not just quality issues. The practical conclusion is to couple software supply chain review with execution-aware telemetry.

Short-lived publishing identities reduce one attack path, but governance still matters more than token format. OIDC-based trusted publishing removes a class of long-lived secret exposure, yet this incident shows that the workflow logic itself can be the weak point. That means the control problem shifts upward into approval logic, repository trust boundaries, and release job design. NHI governance must extend to automation identities that can mint publish rights on demand.

Credential theft from build systems is a precursor to wider identity compromise. Once malicious installation code can inspect GitHub sessions, cloud metadata, and local credential stores, the attack stops being a package issue and becomes an identity incident. The governance gap is standing access inside ephemeral systems. Teams should design CI/CD and developer environments so that package execution cannot reach high-value credentials by default.

From our research:

• 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.
• From our research: Shai Hulud npm malware campaign shows how malicious package execution can exfiltrate secrets through trusted software distribution paths.

What this signals

Package publication workflows are becoming identity systems. Once a release job can mint publishing authority through OIDC, the workflow itself needs lifecycle governance, not just pipeline hygiene. Teams should expect more abuse of comment-triggered automation, especially where a trusted workflow can still check out untrusted code and publish from that context.

CI/CD environments that can execute package lifecycle hooks should be assumed credential-rich and attackable. That pushes organisations toward stricter isolation, narrower secret exposure, and stronger auditability around build identities, especially where repository automation can touch cloud or GitHub credentials.

Installation-time telemetry now matters as much as artifact scanning. Endpoint-style visibility in runners, combined with package provenance checks, is what exposes the difference between a legitimate dependency and a package that is actively harvesting identities. This is where build security and NHI governance converge.

For practitioners

• Lock release workflows to authorized actors Require explicit repository role checks and protected-review approval before any publish step can run. Do not rely on comment text alone to gate a release job, and separate trigger validation from publication permissions.
• Isolate install-time execution Run dependency installation in environments that cannot reach production credentials, signing keys, or cloud metadata. Treat npm lifecycle scripts as code execution and block them where the package source is not fully trusted.
• 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. Remove standing access where a workflow can mint publish rights without human authorization.
• Scan for malicious package indicators Search build logs, caches, and endpoints for suspicious filenames, large package deltas, temporary trinnyyyy directories, and unexpected Bun execution during install. Use these indicators to scope exposure across CI and developer machines.

Key takeaways

• This incident shows that a publish workflow can become a credential theft path when untrusted pull request activity reaches trusted publishing rights.
• The scale of the risk is not theoretical: malicious package code can execute during installation, reach GitHub and cloud targets, and do so inside minutes of exposure.
• The decisive control is not just package review, but authorization on the workflow identity, install-time isolation, and fast credential rotation from a clean environment.

Key terms

• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.
• Lifecycle Script: A lifecycle script is code that runs automatically during package installation or build steps, such as preinstall or postinstall hooks. These scripts are useful for legitimate automation but create a high-risk execution path because they can run before developers fully inspect the package.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Native Build Path: A package execution route that uses native build metadata such as binding.gyp or node-gyp to run commands during installation. Attackers can hide malicious behaviour in these paths because defenders often focus on JavaScript files and overlook build-time evaluation.

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.

👉 StepSecurity's full post covers the attack chain, indicators of compromise, and recovery steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect release workflow risk to access control, lifecycle discipline, and privileged automation oversight.