Key Takeaways<\/p>\n
- \n
- The entry point was in the CI misconfig, long before the registry token.<\/strong> pull_request_target with checkout of the untrusted head, broad GITHUB_TOKEN and subsequent bot push: secret exfiltration and branch compromise go hand in hand.<\/li>\n
- Payload at require(), the active runtime was slimmer than the bundle.<\/strong> ShellExec, persistence and C2 ran. Harvesting, propagation and evasion were in the package, toggleable in this release.<\/li>\n
- Lockfiles from the 07:10-11:18 UTC window remain risky.<\/strong> npm unpublishes the versions; existing pins and CI caches not.<\/li>\n<\/ul>\n<\/div>\n
Related:<\/span>An npm package that stole private keys<\/a> \/<\/span> Mini Shai-Hulud: npm Supply-Chain Worm and Defense<\/a><\/p>\n
What exactly happened<\/h2>\n
On July 14, 2026 at 06:58 UTC, a commit landed in the asyncapi\/generator repository on the branch next under the placeholder identity \u201cYour Name\u201d \/ you@example.com. Twelve minutes later, the legitimate workflow release-with-changesets.yml published three packages with valid npm-OIDC provenance: @asyncapi\/generator@3.3.1, @asyncapi\/generator-helpers@1.1.1 and @asyncapi\/generator-components@0.7.1.<\/p>\n
According to the Microsoft Security Blog, the initial access previously occurred via PR #2155 against the workflow manual-netlify-preview.yml. The workflow used pull_request_target and checked out the untrusted head commit. The GITHUB_TOKEN was broadly privileged; checkout credentials remained in the local Git config until the post-job cleanup. Subsequently, it was pushed using the asyncapi-bot account. Microsoft cautiously suggests that exactly this credential may have been compromised. While the pwn-request entry point and the subsequent bot-push chain are documented and explain the move into the release branch, they do not definitively prove that this specific credential was stolen.<\/p>\n
Important for context: there was no stolen npm publish token. The publish path ran through OIDC trusted publishing. The trust breach occurred earlier, in the CI and push rights on the branch that triggers the release workflow.<\/p>\n
\n~4 h<\/div>\nExposure window until unpublishing of Generator packages<\/p>\n
Source: StepSecurity-Timeline, July 14, 2026 UTC<\/p>\n<\/div>\n
Why “Valid Provenance” Falls Short Here<\/h2>\n
npm Trusted Publishing, using OIDC and SLSA attestations, answers a sharp question: Was this artifact generated by the authorized GitHub workflow of this repository? The attestation for the generator packages displayed precisely repo:asyncapi\/generator:ref:refs\/heads\/next, the workflow file, commit SHA and run URL.<\/p>\n
What they do not address: Was the commit that triggered the workflow legitimate and clean? Provenance does not guard against compromised push credentials nor against CI jobs that execute untrusted code with privileged tokens. Anyone who combines pull_request_target with checkout of the PR head, retains secrets in such jobs and keeps branch protection lax on release branches, opens precisely this chain.<\/p>\n
For CISOs and AppSec this is the central lever: Registry signatures and provenance flags alone deem the AsyncAPI case “green”, even though the CI had already shipped the dropper. Controls must verify the source\u2011of\u2011truth and workflow permissions.<\/p>\n
Payload Mechanics Without Install Hook<\/h2>\n
In none of the affected package.json files was there a preinstall\/postinstall script. The dropper started as soon as the poisoned module code was loaded via require(), i.e., during the normal generator run or in CI jobs building AsyncAPI templates.<\/p>\n
Stage 1 spawns a dedicated Node process. Stage 2 fetches a sync.js from an IPFS gateway, stored under OS\u2011specific paths that appear as a benign NodeJS runtime (e.g., ~\/.local\/share\/NodeJS\/sync.js on Linux). Stage 3 decrypts a bundled Miasma\u2011v3 implant. In the delivered configuration, Remote\u2011Shell (ShellExec), Persistence and C2 Beaconing ran over multiple channels (HTTP, Nostr, IPFS, BitTorrent\u2011DHT, Ethereum\u2011Dead\u2011Drop).<\/p>\n
Static analyses by Aikido and Socket also reveal modules in the bundle that were disabled via toggle in this release: recon: false (Credential harvesting does not start), metamorphic: false (Mutation, evasion and AI\u2011tool poisoning disabled) as well as propagate for npm\/pypi\/ruby\/cargo consistently false (no lateral package propagation). The store was in the artifact. The runtime of this wave was a remote shell with persistence and C2. Host forensics remains mandatory because shell access and persistence were active.<\/p>\n
\n - Payload at require(), the active runtime was slimmer than the bundle.<\/strong> ShellExec, persistence and C2 ran. Harvesting, propagation and evasion were in the package, toggleable in this release.<\/li>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/cursor-windows-git-exe-repo-root-code-execution-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/legacyhive-windows-eop-poc-nach-patch-tuesday-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/joomla-icagenda-balbooa-kev-upload-rce-cover-hero-250x141.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/09\/net-when-ai-agents-travel-data-residency-as-46681309.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/09\/net-more-insolvencies-smaller-cases-what-cou-22218328-250x143.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-token-opex-inference-steuert-nicht-das-s-43794747-250x141.jpg\")
<\/span>