Notifications
Clear all
Topic starter
19/08/2026 3:34 pm
TL;DR: A 14 July 2026 compromise of the AsyncAPI ecosystem turned GitHub Actions release automation into malicious trusted publishing after attackers abused a pull_request_target workflow, a stolen privileged token, and legitimate provenance to ship five poisoned package versions, according to Corgea. The incident shows that CI trust boundaries, not just npm token hygiene, now define supply-chain exposure.
NHIMG editorial — based on content published by Corgea: AsyncAPI supply chain compromise via GitHub Actions
By the numbers:
- @asyncapi/specs alone was seeing about 2.74 million weekly downloads.
Questions worth separating out
Q: What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
A: The base repository’s privilege model breaks.
Q: Why are package imports a supply-chain risk even when install scripts are blocked?
A: Because malicious code can execute at require() time.
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.
Practitioner guidance
- 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.
- 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.
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
👉 Read Corgea's analysis of the AsyncAPI supply chain compromise →
AsyncAPI supply chain attack: what CI trust boundaries did teams miss?
Explore further
19/08/2026 4:15 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AsyncAPI supply chain compromise exposed CI trust-boundary failures
