Topic starter
18/08/2026 2:33 pm
TL;DR: Attackers used compromised GitHub push access, not stolen npm tokens, to publish malicious AsyncAPI packages with valid OIDC provenance, showing how trusted CI/CD release workflows can be turned into malware delivery paths, according to StepSecurity. The lesson for practitioners is that provenance proves workflow legitimacy, not commit legitimacy, so push controls and runner egress monitoring matter.
Editorial analysis by NHI Mgmt Group, based on content published by StepSecurity: “Coordinated AsyncAPI Supply Chain Attack: Miasma RAT Delivered via Compromised CI/CD Pipelines in Two Repositories”.
By the numbers:
- Three packages in the AsyncAPI generator monorepo were published at 07:10 UTC carrying an obfuscated dropper that fires when the library is loaded, not on install.
- All five malicious versions were unpublished, with the generator packages exposed for about 4 hours and the specs packages exposed for 2 hours 48 minutes to 3 hours 12 minutes.
- The specs package was pulled transitively by @asyncapi/parser through a ^6.11.1 semver range and saw 2.66M downloads per week.
Key questions
Q: What breaks when a release workflow trusts repository writes too much?
A: A release workflow breaks when the same push authority can also trigger publishing, because a compromised branch can produce a valid artefact chain.
Q: Why do provenance attestations not prevent malicious package releases?
A: Provenance attests to the build path, not the intent or safety of the inputs.
Q: What are the signs that a CI/CD pipeline is being abused through living-off-the-pipeline techniques?
A: Warning signs include unexpected plugin execution, tools reading configuration from the wrong location, unexplained dependency changes, unusual shell behaviour from environment variables, and secrets appearing in logs or standard output.
Practitioner guidance
- Tighten branch protection on release paths Require protected branches, mandatory reviews, and signed commits for any branch that can trigger package publication, including release branches and version-bump branches.
- Separate publishing authority from repository write access Limit who can push to release-triggering branches and ensure the credential that can change code is not automatically the credential that can publish artefacts.
- Inspect workflow-generated provenance for trigger integrity Verify that OIDC attestations are backed by approved commit sources, expected branch names, and controlled workflow files before trusting the published package.
Bottom line: The incident shows that a trusted release workflow can publish malware when repository write access is compromised before the build begins.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:20 pm
Release provenance is not release legitimacy. This incident shows that attestation can prove a workflow executed, yet still say nothing about whether the triggering commit was authorised or safe. That distinction matters because many organisations now treat signed provenance as a substitute for release trust rather than one input into it. Practitioners should therefore evaluate commit control, branch protection, and workflow trust as a single governance chain, not as independent checks.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Compromised CI/CD pipelines turned AsyncAPI release workflows into malware