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.
At a glance
What this is: This is a supply-chain compromise in which AsyncAPI release automation was abused to publish malicious package versions through trusted GitHub Actions paths.
Why it matters: It matters because teams that rely on CI provenance, release branch trust, and dependency imports can still be exposed even when they do not store an obvious npm token in the wrong place.
Context
AsyncAPI is a software supply-chain case, but the real control failure sits in the CI trust boundary. A workflow that can inspect or execute untrusted pull-request code while holding release authority collapses the separation between source review and publishing, which means provenance can become a delivery channel for malware instead of evidence of safety.
For IAM and NHI teams, the identity angle is direct. Release automation often depends on service accounts, GitHub tokens, and signing authority that behave like non-human identities, so lifecycle control, branch protection, and workflow design become identity governance issues as much as DevSecOps issues.
The incident is also a reminder that transitive package consumption broadens blast radius beyond the repository that was directly attacked. A compromise in generator, parser, or schema-validation paths can reach developer workstations and CI jobs that never intentionally opted into the malicious versions.
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 do GitHub Actions release tokens and bot accounts need NHI governance?
A: Because they are delegated non-human identities with real publishing power. If a bot token can sign, publish, or approve release activity, it needs ownership, scope, rotation, and offboarding controls just like any other privileged credential. Otherwise, a single compromised workflow can become a broad supply-chain compromise.
Q: What do security teams get wrong about provenance in software delivery?
A: They often treat provenance as documentation rather than a continuously verifiable control. Provenance only works when the organisation can link source, build inputs, signing actions, and release approvals into one auditable chain with accountable ownership at each stage.
Q: Should teams prioritise CI/CD access governance or package scanning first?
A: Teams should not treat them as separate choices. Package scanning finds risky components, but CI/CD access governance determines who can introduce or approve them. In a high-velocity pipeline, governance over build identities and promotion rights is the control that keeps scanning findings from becoming live exposure.
Technical breakdown
How a pull_request_target workflow breaks the CI trust boundary
pull_request_target is dangerous when a privileged workflow checks out attacker-controlled pull-request code and then executes it. The workflow runs in the security context of the base repository, so secrets, tokens, and release permissions are available before the code has earned trust. The failure is not GitHub Actions itself. The failure is combining untrusted code execution with elevated repository authority, which allows a fork-originated change to behave like an internal release step.
Practical implication: Separate untrusted validation from privileged release jobs and never execute fork-controlled code inside a job that can publish or sign artifacts.
Why import-time loaders are harder to block than postinstall malware
The malicious AsyncAPI packages executed at require() time, which means the payload fired when a package was imported, not only during installation. That makes controls like npm install --ignore-scripts insufficient, because the danger moves into application runtime and CI execution paths. A loader that spawns a detached process can also evade simplistic process monitoring if teams only inspect package-install events instead of module-load behavior.
Practical implication: Treat dependency imports as an execution boundary and scan for top-level code in packages that should behave as passive libraries.
How trusted publishing and provenance still fail under stolen release authority
Trusted publishing and SLSA-style provenance can prove which pipeline produced an artifact, but they cannot prove the pipeline logic was trustworthy or that the release branch was not controlled by an attacker. If a privileged token, release branch, or workflow path is compromised, the pipeline can produce perfectly signed malicious artifacts. In other words, provenance is only as strong as the trust boundary that surrounds the workflow authority.
Practical implication: Harden release branches, scope publishing credentials tightly, and verify workflow integrity before treating provenance as assurance.
Threat narrative
Attacker objective: The attacker aimed to turn the project's own release automation into a malware distribution path for poisoned packages that would reach developers and CI systems.
- Entry occurred through a pull_request_target workflow that could be tricked into running attacker-controlled pull-request content with repository-level trust.
- Credential access followed when the workflow exposed a privileged asyncapi-bot token and the attacker used it to move into release authority.
- Escalation and impact came when unsigned release-branch commits drove legitimate GitHub Actions publishing, producing malicious package versions with valid provenance.
Breaches seen in the wild
- Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
CI trust-boundary failure is now a release-security problem, not just a workflow hygiene issue. The AsyncAPI compromise shows that a privileged workflow can become the delivery mechanism for malicious artifacts when untrusted code is allowed to cross into release authority. That shifts governance from simple token hygiene to control over where code is allowed to execute and what authority the job holds at that moment. Practitioners should treat release automation as an access-control surface, not only a build system.
Non-human identity governance applies directly to GitHub Actions and release tokens. The stolen credential in this case was not a human login, but it still represented delegated authority that could publish artifacts and shape downstream trust. That makes workflow identities, bot tokens, and signing privileges part of the NHI estate. Organisations that inventory service accounts but ignore CI principals are leaving a major identity class outside governance. The control question is who can release, under what conditions, and from which code path.
Trusted provenance is necessary, but not sufficient, when the release branch is the compromise point. Valid provenance can still accompany a malicious package if the attacker has reached the workflow that creates it. This is the named problem of provenance without boundary integrity. For supply-chain programmes, that means release-branch protection, workflow separation, and privilege scoping matter as much as signing. The practitioner conclusion is simple: provenance must be backed by trustworthy pipeline authority.
AsyncAPI-style compromise creates CI governance debt. The same repository design mistakes that expose one package family can spread through generators, schema packages, and transitive consumers before anyone notices. The governance debt is not only in the vulnerable workflow but also in the assumption that import paths are harmless and that signed builds equal safe builds. Security teams should assume their CI identity model is part of the attack surface and govern it accordingly.
What this signals
CI trust boundaries should now be treated as identity boundaries. When a bot token or workflow principal can both inspect untrusted code and release artifacts, the system has no meaningful separation between validation and authority. That is why release automation needs the same lifecycle discipline as other privileged non-human identities, including scope review, offboarding, and branch-level containment.
Trusted publishing only works when the release path itself is trustworthy. Organisations that rely on provenance without isolating forked code, release branches, and privileged workflow steps are assuming away the exact failure this incident demonstrates. The better governance model is to validate untrusted input in one plane and reserve release authority for a separate, tightly controlled plane.
For practitioners
- Split untrusted PR validation from privileged release paths Keep pull_request_target jobs free of checkout-and-execute patterns, and move build or test execution for forked code into an unprivileged pipeline that cannot access secrets or publish artifacts.
- Inventory CI principals as non-human identities Map GitHub bots, release tokens, and signing credentials to owners, scopes, and expiry dates so release authority is visible alongside human account access.
- Audit package imports for top-level execution Search for modules that run code at require() time, especially in generator, parser, and schema-validation dependencies that are imported in CI or developer tooling.
- Rotate every secret exposed to build hosts Treat developer workstations and CI runners that imported affected versions as potentially compromised and rotate GitHub, npm, SSH, cloud, and browser-held credentials.
- Verify release-branch protections and signing gates Require branch protection, workflow review, and separate release authority so a compromised contributor path cannot directly drive published artifacts.
Key takeaways
- The incident exposes a CI trust-boundary problem, not just a package-hygiene problem, because the attacker used privileged workflow execution to publish malicious packages.
- The highest-risk control gap was letting untrusted pull-request code approach release authority, which let the project’s own automation become part of the compromise path.
- Teams need to govern release bots, workflow permissions, and branch protections together, because provenance alone does not prevent malicious publication when the pipeline is already breached.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The compromised release automation behaved like a third-party identity path that could publish malicious artifacts. |
| NHI-05 — Overprivileged NHI | The workflow and bot token had more authority than untrusted code should ever touch. | |
| Recommendation — Review third-party and delegated release identities for scope, ownership, and isolation gaps. Reduce release and workflow privileges to the minimum needed for each pipeline stage. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack moved from workflow trust abuse into privileged credential use and release-path expansion. |
| Recommendation — Map workflow abuse to TA0006 and TA0008 to hunt for credential misuse and release-path pivoting. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The incident hinges on token handling, rotation, and the lifecycle of privileged release credentials. |
| Recommendation — Apply IA-5 to govern token issuance, rotation, revocation, and scope for CI principals. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Release automation permissions determined whether untrusted code could reach trusted publishing. |
| Recommendation — Use PR.AA-05 to enforce separate permissions for validation, build, and publication roles. | ||
| CIS Controls v8 | CIS-5 — Account Management | CI bots and release service accounts need explicit account management and offboarding controls. |
| Recommendation — Manage CI accounts as privileged identities with owners, reviews, and timely deprovisioning. | ||
Key terms
- Pull_Request_Target Trust Boundary: A pull_request_target trust boundary exists when a privileged workflow runs in the context of the base repository while handling code from an untrusted fork or branch. The risk is that secret-bearing automation can execute attacker-controlled logic before the code has been vetted.
- 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.
- Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
- Provenance: Provenance is the traceable history of where a software artifact came from, who approved it, and what controls were applied along the way. In container security, provenance supports trust decisions because it links delivery steps to accountable identities and review points.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is suitable for security and identity teams that need to govern non-human credentials, workflow identity, and delegated access.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org