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.
NHIMG editorial — based on content published by StepSecurity: Coordinated AsyncAPI Supply Chain Attack with Miasma RAT delivered via compromised CI/CD pipelines
By the numbers:
- The attacker published three malicious generator packages through the legitimate release workflow within 12 seconds of the commit landing.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Tighten branch protection on release-bearing repositories Require code-owner review, signed commits, and restricted push rights on branches that can trigger publishing workflows.
- Limit CI/CD workflow trigger authority Review which events can invoke release jobs, especially push-based triggers, version tags, and commit-message patterns.
- 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.
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
👉 Read StepSecurity's analysis of the AsyncAPI CI/CD supply chain attack →
AsyncAPI supply chain attack: what CI/CD compromise means for teams?
Explore further
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.
A few things that frame the scale:
- At the NHI layer, exposure windows are brutally short: 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.
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: Compromised CI/CD pipelines turned AsyncAPI release workflows into malware