Compromised CI/CD pipelines turned AsyncAPI release workflows into malware

At a glance

What this is: This is an analysis of a coordinated AsyncAPI supply chain attack in which compromised repository access allowed malicious npm packages to be published through legitimate CI/CD workflows.

Why it matters: It matters because identity, privilege, and release governance all failed at the same point, which is exactly where NHI, service-account, and pipeline controls need to be strongest.

By the numbers:

• The attacker published three malicious generator packages through the legitimate release workflow within 12 seconds of the commit landing.

👉 Read StepSecurity's analysis of the AsyncAPI CI/CD supply chain attack

Context

Supply chain attacks succeed when release automation is trusted more than the identity and integrity of the change that triggered it. In this case, the primary security gap was not package signing, but the ability to push malicious commits into repositories that were wired directly into publishing workflows. For IAM and NHI teams, that is the same pattern seen when a non-human identity has standing privilege with no meaningful lifecycle control.

StepSecurity's analysis shows why provenance alone is not a sufficient control boundary. The release pipeline was doing exactly what it was configured to do, which means the governance failure sat upstream in repository access, branch protection, and CI/CD trust assumptions. That is a common pattern in modern supply chain compromise, and it is especially relevant where automation can act on behalf of identities that are not continuously verified.

The topic intersects directly with NHI governance because GitHub Actions, OIDC trusted publishing, and automation tokens are all non-human identities in practice. The article's starting point is unfortunately typical for contemporary CI/CD compromise: an attacker does not need to steal a registry token if they can abuse the repo identity that controls the workflow.

Key questions

Q: What breaks when CI/CD release workflows can be triggered by a compromised push credential?

A: The release pipeline becomes an attacker-controlled publishing path. If push access can invoke package publication, the attacker no longer needs to steal registry tokens or compromise the package manager. The practical failure is that trusted automation authenticates the workflow, not the intent of the commit that started it.

Q: Why do provenance attestations not fully solve supply chain compromise?

A: Provenance proves which workflow produced the artifact, but it does not prove the triggering change was authorised or safe. If repository access, branch protection, or workflow triggers are weak, a malicious commit can still produce a validly attested package. Assurance needs source integrity and workflow integrity together.

Q: How do security teams know if a package compromise has become runtime execution?

A: Look for behaviour that occurs when the package is imported, not only when it is installed. Detached Node processes, dropped files such as sync.js, unexpected outbound IPFS or HTTP traffic, and changes in user-level startup paths are strong indicators that malicious code has moved from dependency risk into active execution.

Q: Who is accountable when a release workflow publishes malicious code through trusted publishing?

A: Accountability spans repository owners, release engineers, and platform teams that control branch protections and workflow permissions. Trusted publishing shifts responsibility upward into the CI/CD identity layer, so organisations need clear ownership for who can trigger releases, approve workflow changes, and monitor execution behaviour.

Technical breakdown

How compromised push access became package publication

The attack chain began with repository write access, not registry compromise. Once the attacker could push to the target branch, they inserted a dropper into source files and let the legitimate release workflow package and publish the code. Because the publishing path used GitHub Actions with OIDC trusted publisher integration, npm saw an authenticated workflow run and issued valid provenance attestations. That proves the workflow identity was real, but it does not prove the commit identity was trustworthy. The critical architectural issue is that release automation often treats branch push rights as equivalent to publication authority.

Practical implication: separate commit rights from publish rights and enforce branch and workflow protections that assume push access can be abused.

Why provenance did not stop the malicious release

Provenance and signing verify where the artifact came from, but they do not validate whether the triggering change was benign. In this case, the attacker used the project's own CI/CD path, so the resulting packages carried legitimate SLSA-style attestations even though the content was malicious. That is a subtle but important distinction for software supply chain governance. Trusted publishing reduces token theft risk, but it also raises the bar for repository and workflow security because the workflow itself becomes the enforcement point. If that point is compromised, provenance becomes evidence of process, not innocence.

Practical implication: treat provenance as one control layer and require commit, branch, and workflow integrity checks before publication.

How the malware shifted from install-time to load-time execution

The dropper did not execute on npm install. It fired when the library was required during normal use, which is a more effective evasion technique because it blends into build jobs and runtime automation. The second stage fetched payloads from IPFS and then reached out to multiple C2 channels, including HTTP, Nostr, and BitTorrent DHT. That multi-channel design is resilient because blocking one route does not neutralise the whole operation. For defenders, the important lesson is that package inspection alone is insufficient if the payload is dormant until application runtime.

Practical implication: inspect package behaviour in CI/CD and runtime contexts, not just during dependency installation.

Threat narrative

Attacker objective: The attacker aimed to distribute a load-time malware payload through trusted software supply chain channels while preserving the appearance of legitimate release activity.

1. Entry occurred through compromised repository push access, allowing the attacker to modify release-triggering branches without stealing an npm token.
2. The attacker escalated by using the project's legitimate GitHub Actions release workflows and OIDC trusted publishing path to turn repository access into package publication authority.
3. Impact followed when malicious npm releases were published with valid provenance and could be consumed by downstream builds and transitive dependencies.

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

Trusted publishing shifts the control point, but it does not remove the identity problem. OIDC-based package publication reduces secret theft, yet the real security question becomes who can trigger the workflow and under what conditions. In this attack, the release pipeline was functioning as designed, which means the governance gap sat in branch control and repository trust rather than the registry itself. Practitioners should treat the workflow trigger as a privileged boundary, not a convenience feature.

Provenance is necessary, but it is not sufficient for supply chain assurance. SLSA-style attestations can prove which workflow produced an artifact, but they cannot prove the source commit was authorised or clean. That distinction matters for identity governance because it mirrors the difference between authenticating an actor and authorising an action. Teams need commit integrity, protected branches, and workflow attestation together, not as substitutes for one another.

CI/CD pipelines are becoming non-human identity estates that need lifecycle governance. GitHub Actions runners, repository write privileges, OIDC trust relationships, and release automation all behave like machine identities with delegated authority. The named failure mode here is compromised publish privilege through CI/CD trigger abuse, where a single push path becomes enough to publish malware. That should push security teams to inventory pipeline identities, bound their scope, and review who can activate release automation.

Load-time payloads make package security a runtime problem, not only a dependency problem. The malware firing on require() means defenders cannot stop at static package vetting or install-time scanning. Runtime inspection, egress control, and build isolation become part of supply chain governance because the malicious behaviour emerges after the package is already trusted. For practitioners, that expands the control surface from source integrity to execution containment.

Decentralised C2 and hidden staging channels are now part of modern package malware tradecraft. The attack used IPFS, Nostr, and BitTorrent DHT to diversify command and control routes, which complicates response and takedown efforts. That signals a broader shift in attacker resilience: compromise paths are being designed to survive single-point network blocks. Teams should assume package malware may use multiple infrastructure layers and validate egress baselines accordingly.

From our research:

• At the NHI layer, exposure windows are brutally short: From our research: When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research also shows that 64% of valid secrets leaked in 2022 are still valid and exploitable today, which is why detection without revocation leaves real residual risk.
• For teams hardening their identity estate, the Ultimate Guide to NHIs frames why machine-identity growth and breach frequency have made lifecycle governance a board-level issue.

What this signals

CI/CD compromise is becoming an identity governance problem as much as a software security problem. Once release automation can publish on behalf of a repository identity, the next control question is who can activate that identity, under what conditions, and how quickly misuse can be detected.

Compromised publish privilege: this is the failure mode practitioners should name when a repository push turns into trusted artifact publication. The control gap is not just token theft. It is the absence of binding between the actor who made the change, the workflow identity that shipped it, and the egress policy that would have contained it.

Teams should expect more attacks that blend code review evasion, trusted publishing, and runtime payload staging. That means branch controls, workflow permissions, and runner egress baselines need to be treated as part of the same governance layer, not three separate projects.

For practitioners

• Tighten branch protection on release-bearing repositories Require code-owner review, signed commits, and restricted push rights on branches that can trigger publishing workflows. Separate routine development branches from branches that can publish artifacts, and treat release branches as privileged assets. This closes the exact path abused in the AsyncAPI compromise.
• Limit CI/CD workflow trigger authority Review which events can invoke release jobs, especially push-based triggers, version tags, and commit-message patterns. Where possible, move to manually approved or policy-gated release steps so a single compromised push cannot reach package publication. Map these triggers as non-human identities with delegated authority.
• Monitor runner egress and child-process behaviour Baseline expected network destinations for build jobs and block unexpected outbound access such as IPFS gateways, DHT nodes, or unusual HTTP C2 endpoints. Also alert on detached child processes, hidden directories, and scripts written outside standard build paths. Those signals are strong indicators of staged supply chain malware.
• Validate provenance and commit integrity together Do not accept provenance attestations as proof that a release is safe. Pair attestation checks with review of the triggering commit, branch state, signer identity, and workflow context so malicious code cannot inherit trust from a legitimate pipeline. This is especially important for trusted-publisher integrations.

Key takeaways

• This attack worked because repository push rights were allowed to become release authority, which is a CI/CD identity failure, not a registry failure.
• Valid provenance did not make the packages safe, and the exposure window was long enough for downstream consumption after publication.
• The practical response is to harden branch protection, reduce workflow trigger power, and monitor build egress as part of supply chain governance.

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.
• Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
• Release Workflow: An automated pipeline that turns source changes into a published package, container, or artifact. In supply chain security, it is a privileged non-human identity because it can transform repository activity into externally consumable software.
• Load-Time Dropper: Malicious code that activates when a package is imported or required rather than when it is installed. This design lets attackers avoid simple install-time scanning and blend execution into normal application, build, or CI/CD runtime behaviour.

What's in the full article

StepSecurity's full analysis covers the operational detail this post intentionally leaves for the source:

• Commit-by-commit attack timeline across both AsyncAPI repositories, including the exact workflow runs that published each malicious version
• Static decoding notes for the obfuscated dropper and the stage-two Miasma RAT payload architecture
• Runtime telemetry from monitored GitHub Actions jobs showing the outbound channels used by the payload
• Exposure-window and remediation chronology for each affected package version

👉 StepSecurity's full post covers the commit trail, payload staging, and network telemetry behind the malicious releases.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners translate identity controls into release, runtime, and lifecycle decisions.