AsyncAPI supply chain compromise exposed CI trust-boundary failures

At a glance

What this is: This is an analysis of the AsyncAPI package compromise in which attackers turned a GitHub Actions trust-boundary failure into malicious package publishing with legitimate provenance.

Why it matters: It matters because AppSec, DevOps, and identity teams need to treat CI tokens, release branches, and developer workstation imports as shared trust surfaces, not separate problems.

By the numbers:

• @asyncapi/specs alone was seeing about 2.74 million weekly downloads.
• Wiz says the attacker opened 37 pull requests against the generator repository.

👉 Read Corgea's analysis of the AsyncAPI supply chain compromise

Context

Supply-chain incidents increasingly begin in CI trust decisions rather than in public package registries. When a workflow can execute untrusted pull-request code with elevated repository authority, a maintainer token becomes only one part of the blast radius, because release automation can be coerced into publishing attacker-controlled artifacts with apparent legitimacy.

For identity and access practitioners, the key issue is not just code integrity. This incident shows how release permissions, GitHub Actions tokens, branch protections, and developer workstation imports intersect with secrets, workload identity, and endpoint exposure. That makes it a governance problem across IAM, PAM, NHI, and AppSec rather than a narrow npm compromise.

This pattern is increasingly typical in modern software delivery, especially where pull_request_target and checkout-and-execute habits still coexist in release pipelines.

Key questions

Q: What breaks when pull_request_target is used to run untrusted code in GitHub Actions?

A: The base repository’s privilege model breaks. pull_request_target can expose secrets and write-capable tokens, so if the workflow checks out and runs fork-controlled code, attacker content inherits release authority. That can turn a routine pull request into a compromise of signing, publishing, or secret-bearing jobs.

Q: Why are package imports a supply-chain risk even when install scripts are blocked?

A: Because malicious code can execute at require() time. If a dependency includes a top-level loader, normal application startup, code generation, or schema validation can trigger malware without any postinstall hook. Blocking install scripts reduces one path, but it does not stop import-triggered execution in trusted runtime contexts.

Q: How should security teams verify software provenance before production release?

A: Security teams should require cryptographic attestations that bind an artifact to its source commit, build environment, and signer, then enforce those checks at deployment time. Provenance is only useful when the release pipeline can reject artifacts that do not meet policy. Scanning and SBOMs help, but they do not prove integrity on their own.

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 pull_request_target turns untrusted code into privileged execution

GitHub Actions pull_request_target runs in the security context of the base repository, which means it can access repository secrets and a write-capable token if the workflow grants it. The failure occurs when the workflow checks out code from the pull request and then executes that code inside the same privileged job. That is a trust-boundary collapse, because fork-controlled content inherits release authority. In this incident, the attacker only needed one successful run to bridge from untrusted input into a privileged CI environment.

Practical implication: separate untrusted validation from any job that can sign, publish, or access release secrets.

Why import-time loaders are more dangerous than postinstall scripts

The malicious AsyncAPI packages executed at require() time, not through npm install lifecycle hooks. That matters because many defenses focus on blocking postinstall scripts while assuming imported dependencies are safe until explicit execution. A top-level loader runs as soon as the module is loaded by generator, parser, or schema tooling, which makes routine developer or CI workflows sufficient to trigger malware. The dangerous boundary is dependency resolution followed by import, not installation alone.

Practical implication: inspect dependency execution paths, not just install scripts, when assessing supply-chain risk.

How legitimate provenance can still hide a compromised release path

Provenance shows where an artifact was built, but not whether the branch logic, workflow trigger, or effective authority was trustworthy. In this case, public reporting says the packages were released through legitimate GitHub Actions pipelines with valid SLSA provenance. That is consistent with compromise, because an attacker who controls the release branch or the workflow’s execution context can still produce signed-looking malicious artifacts. Provenance is necessary evidence, but it is not a substitute for release-path hardening.

Practical implication: treat provenance as one control layer and harden branch protection, token scope, and workflow isolation separately.

Threat narrative

Attacker objective: The attacker aimed to convert trusted release automation into a signed distribution channel for malware and secret theft.

1. Entry occurred through a pull_request_target workflow that accepted attacker-influenced pull-request content inside a privileged GitHub Actions job.
2. Credential access followed when the workflow exposed a privileged repository token that the attacker used to push unsigned changes into release paths.
3. Impact was the publication of malicious AsyncAPI package versions with legitimate release provenance, creating downstream compromise risk for developers and CI jobs that imported them.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

CI trust boundaries are now part of identity governance. This incident was not primarily an npm problem. It was a delegation problem in which a workflow inherited more authority than the code it executed should have had. That means release pipelines need governance comparable to privileged identity lifecycle management, including narrow token scope, branch protection, and separation of untrusted and trusted execution.

Import-time malware changes the control surface for AppSec and NHI teams. The dangerous event was not installation but module loading, which means scanners that only monitor lifecycle scripts will miss a class of active supply-chain threats. The named concept here is import-time execution exposure: a dependency becomes an execution vector the moment it is required, so runtime policy must extend into developer and CI environments.

Provenance without workflow integrity is an incomplete control. Valid signatures and SLSA evidence can describe artifact origin while still masking a compromised release path. This matters to practitioners because trust decisions must include who could trigger the pipeline, who could alter the branch, and which identities were allowed to publish. The governance conclusion is straightforward: provenance helps, but it cannot compensate for weak release authority.

Developer workstations and CI runners should be treated as shared secret-bearing assets. The article shows how browser credentials, cloud tokens, SSH keys, and GitHub tokens can all be reachable once a malicious dependency executes. That creates a cross-domain control problem across endpoint, IAM, and NHI governance. Practitioners should assume package imports can become endpoint compromise events, not just dependency hygiene issues.

Release automation is becoming a privileged identity problem in software supply chains. The more a pipeline can sign, publish, and promote artifacts without human review, the more it resembles a high-value non-human identity. That shifts attention from single-token theft to lifecycle control over workflow identities, release branches, and transient job credentials. Teams should govern these automation identities as if they were privileged service accounts.

From our research:

• The affected AsyncAPI package family sees more than 3 million weekly downloads combined, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 52 NHI Breaches Analysis expands the control-failure patterns that let trusted automation become a compromise channel.

What this signals

Import-time execution exposure: teams should now treat dependency loading as an execution event, not a passive read. That shifts control design toward runtime monitoring, tighter CI isolation, and dependency allowlisting for codegen and schema tooling, with release identities governed like other privileged automation.

The article also reinforces a broader platform signal: provenance, package signing, and trust metadata are necessary but not sufficient when workflow authority is mis-scoped. Practitioners should align release governance with NIST SP 800-53 Rev 5 Security and Privacy Controls and review whether their CI identities behave like controlled service accounts or like implicit superusers.

For practitioners

• Split untrusted and privileged GitHub Actions jobs Move pull-request validation into a non-privileged workflow and reserve release signing, publishing, and secret access for protected branches only. Avoid any pattern where pull_request_target checks out and runs fork-controlled code.
• Review dependency import paths for runtime execution Inspect generator, parser, and schema-validation packages for code that executes at require() time, then flag those dependencies for extra scrutiny in CI and developer environments.
• Rotate every secret exposed to imported packages Assume any host that imported the affected packages may have leaked GitHub tokens, npm tokens, SSH keys, cloud credentials, or browser session data, and rotate them before resuming normal builds.
• Harden release branches as privileged assets Apply branch protection, review enforcement, and token minimisation to release branches so a compromised workflow cannot silently push unsigned changes into a publish path.
• Search for persistence and exfiltration indicators on developer hosts Look for the cited stage-two CIDs, the miasma-monitor.service user service, and the NodeJS sync.js path in endpoint telemetry, home directories, and user services.

Key takeaways

• This incident exposed a CI trust failure, not just a package compromise, because privileged release automation executed attacker-influenced code.
• The scale is material for defenders, with more than 3 million weekly package downloads across the affected family and transitive reach into common build paths.
• Teams should harden workflow authority, reduce token scope, and treat import-time execution as a control boundary in supply-chain defence.

Key terms

• Pull_request_target workflow: A GitHub Actions trigger that runs in the context of the base repository, not the contributor’s fork. That means it can access repository secrets while processing untrusted pull request content, which creates a sharp trust boundary and a common route to secret theft if not carefully segmented.
• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• 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.
• Release Branch Governance: The set of controls that limit who can alter, approve, or promote code from release branches. In supply-chain incidents, weak branch governance can let attacker-controlled changes reach signed or published artifacts even when provenance looks valid.

What's in the full report

Corgea's full research covers the operational detail this post intentionally leaves for the source:

• Commit-level indicators, including the suspicious release-branch history and unsigned malicious changes that support scoping
• Payload analysis details for the stage-two downloaders, persistence behaviour, and exfiltration targets
• Endpoint and CI hunting guidance for the specific CIDs, service names, and filesystem locations reported in the compromise
• Repository-level context on how pull_request_target and release automation combined to create the trust-boundary failure

👉 The full Corgea post covers the release-path evidence, loader behaviour, and response indicators in more detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and access lifecycle control. It helps practitioners connect identity governance to the release, build, and automation systems that now carry real operational risk.