[SECURITY] Malicious versions published via compromised next branch - @asyncapi/generator@3.3.1, generator-helpers@1.1.1, generator-components@0.7.1

[LidorMachluf]

Summary

Three malicious versions of AsyncAPI packages were published to npm on 2026-07-14 at 07:10 UTC via a compromised CI workflow. A threat actor gained write access to the next branch and pushed a commit injecting a credential-stealing RAT dropper into the source of all three packages. All three versions are currently promoted as latest on npm.

The AsyncAPI project and its maintainers are victims of this attack - this is not an insider issue.

---

Affected Versions

Package	Malicious Version	Safe Version
@asyncapi/generator	3.3.1	3.3.0
@asyncapi/generator-helpers	1.1.1	1.1.0
@asyncapi/generator-components	0.7.1	0.7.0

---

What Happened

The compromised commit

Commit 3eab3ec9304aa26081358330491d3cfeb55cc245 was pushed to the next branch at 06:58:42 UTC with author identity "Your Name" / you@example.com - an unconfigured placeholder git identity, not any AsyncAPI contributor.

The commit modified three source files in the monorepo, injecting a ~7.7KB obfuscated JavaScript payload as a whitespace-padded single line (hidden ~1000 spaces off-screen) in each:

• apps/generator/lib/templates/config/validator.js (line 69)
• packages/helpers/src/utils.js
• packages/components/src/utils/ErrorHandling.js

The release workflow on the next branch triggered automatically, and asyncapi-bot published all three packages via GitHub Actions OIDC within seconds.

Note: apps/react-sdk/src/utils/withNewLines.ts was also modified in the same commit with a different IPFS payload CID (Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf). No matching npm package appears to have been published, but the @asyncapi/react-component scope should be audited.

---

Attack Chain

Stage 1 - fires at require() time (no install hook needed)

The injected IIFE runs immediately when the poisoned file is require()d during normal generator operation:

// Decoded from obfuscated blob in validator.js:69
spawn("node", ["-e", "<stage2_script>"], {
  detached: true,
  stdio: "ignore",
  windowsHide: true
}).unref()

No postinstall hook - the payload fires when the generator is used, not when it is installed.

Stage 2 - IPFS downloader (decoded from stage 1)

The inline script:

1. Creates a hidden directory based on OS:
   • Linux: ~/.local/share/NodeJS/
   • macOS: ~/Library/Application Support/NodeJS/
   • Windows: %LOCALAPPDATA%\NodeJS\
2. Downloads sync.js (8.25MB) from IPFS CID QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9
3. Executes it silently: spawn("node", ["<dir>/sync.js"], {detached: true, stdio: "ignore", windowsHide: true}).unref()
4. Calls process.exit(0) - the parent exits cleanly, hiding any trace

Stage 3 - Miasma RAT (sync.js, fully decrypted)

sync.js is a self-decrypting AES-256-GCM payload (HKDF-SHA256, hardcoded master key rt-vault-master-key-32b-aaaaaaaa). Once decrypted it is a full credential-stealing RAT with:

Credential targets:

• Browser profiles: Login Data, Cookies, Local State (Chrome, Brave, Firefox, Edge)
• SSH keys: ~/.ssh/id_rsa, ~/.ssh/id_ed25519, ~/.ssh/config
• npm token: ~/.npmrc
• GitHub CLI: ~/.config/gh/
• AWS: ~/.aws/credentials
• Git config: ~/.gitconfig
• macOS Keychain
• Crypto wallets: MetaMask, Ledger

C2 infrastructure:

• HTTP exfil: http://85.137.53.71:8081 (NL, AS43641 SOLLUTIUM EU) - confirmed live at time of discovery
• Ethereum smart contract dead-drop: 0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710 (mainnet)
• Nostr relay C2: wss://relay.damus.io, wss://relay.nostr.com/

Campaign: Internal config identifies this as "miasma-train-p1" - part of the Miasma campaign active since June 2026, which previously targeted @vapi-ai/server-sdk, packages in the jagreehal GitHub org, and the @redhat-cloud-services scope.

---

Indicators of Compromise

Type	Value
Malicious commit	3eab3ec9304aa26081358330491d3cfeb55cc245
IPFS CID (stage 2)	QmQobZSp1wRPrpSEQ56qnyq7ecZh5Bg5k1fnjt4SUwwHb9
IPFS CID (react-sdk variant)	Qmet4fhsAaWMBUxNDfREHwgiyDeSWy4YSYs9wiKUW5jGyf
C2 / exfil IP	85.137.53.71 (NL, AS43641)
Ethereum contract	0x12c37A86a0Ed0beBe5d1d6a43E42f07860eAc710
Drop file (Linux)	~/.local/share/NodeJS/sync.js
Drop file (macOS)	~/Library/Application Support/NodeJS/sync.js
Drop file (Windows)	%LOCALAPPDATA%\NodeJS\sync.js
Obfuscator fingerprint	function _0x2d89, rotation constant 0x32b8b

---

Recommended Actions

For AsyncAPI maintainers (urgent)

• Rotate all GitHub tokens and secrets - PATs, Actions secrets, deploy keys - the next branch write token is compromised
• Audit branch protection on next - identify how the attacker gained push access; remove unknown keys
• Force-push or delete the next branch to remove commit 3eab3ec9 (coordinate with GitHub Security if they want to preserve it for forensics)
• Audit all @asyncapi scope packages for unauthorized versions published in the 07:05-07:15 UTC window today
• Publish clean patch versions (3.3.2, 1.1.2, 0.7.2) once npm yanks the malicious ones, so users upgrading land on something safe
• Publish a security advisory linking to this issue

For users who installed any affected version after 2026-07-14 07:10 UTC

1. Check for the dropped file and delete if present:
   • Linux: ~/.local/share/NodeJS/sync.js
   • macOS: ~/Library/Application Support/NodeJS/sync.js
   • Windows: %LOCALAPPDATA%\NodeJS\sync.js
2. Kill orphaned node processes originating from those directories
3. Rotate credentials - treat all of the following as compromised: npm token, GitHub token, SSH private keys, AWS credentials
4. Treat browser saved passwords as compromised - Chrome, Brave, Firefox, and Edge profile data was targeted
5. Downgrade immediately to the safe versions listed above

---

Reported by Lidor Machluf / Upwind Security

[github-actions]

Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

[derberg]

reported to npm to remove these versions

[varunsh-coder]

We at StepSecurity are also closely tracking this incident and have shared our findings here:
https://www.stepsecurity.io/blog/compromised-next-branch-pushes-malicious-asyncapi-generator-generator-helpers-and-generator-components-to-npm

[abhisek]

@derberg May be stop release/rotate tokens (if any) right away. @asyncapi/specs@6.11.2 just got hit as well it seems.

[kiran-sec]

We’ve confirmed @asyncapi/specs@6.11.2 (and 6.11.2-alpha.1) are also compromised @derberg

[LidorMachluf]

Update: @asyncapi/specs also compromised (same attacker, separate repo)

The same attacker (GitHub user ID 148100) also compromised the alpha branch of asyncapi/spec-json-schemas on the same day.

Additional malicious packages:

Package	Version	Tag	Published
@asyncapi/specs	6.11.2-alpha.1	alpha	2026-07-14 08:06 UTC
@asyncapi/specs	6.11.2	latest	2026-07-14 08:30 UTC

Safe pin: @asyncapi/specs@6.11.1

This is a separate repo and token compromise - rotating only the generator repo tokens is not sufficient. The asyncapi/spec-json-schemas repo's alpha branch write token also needs to be rotated independently.

Dedicated issue: asyncapi/spec-json-schemas#656

[abhisek]

@LidorMachluf The miasma attribution seems wrong here. See https://safedep.io/inside-the-miasma-supply-chain-attack-toolkit/

[raphabot]

Do we know how the threat actor gained write access to the next branch?

[LidorMachluf]

Thanks for the pointer @abhisek - that's a fair challenge and worth clarifying.

You're right that the technical fingerprints in the SafeDep Miasma writeup (GitHub dead-drop C2 markers like DontRevokeOrItGoesBoom/TheBeautifulSandsOfTime, PBKDF2 string vault, AES-128-GCM + ROT-N outer shell, GitHub commit exfil) do not appear in the payload we decoded here. We looked for them specifically after reading your article and confirmed no overlap.

What we actually found that led to the Miasma label:

The attribution comes entirely from the attacker's own internal naming in the decrypted payload - not from matching your documented fingerprints:

1. Decrypted baked config JSON contains: "target": {"name": "miasma-train-p1"}
2. RAT source persistence directory: ~/.miasma/
3. Worm propagation module filename: phantom-gyp.js

The toolchain itself is different from what you documented - this payload uses HKDF-SHA256 (not PBKDF2), AES-256-GCM (not 128), Ethereum + Nostr + IPFS for C2 (not GitHub dead-drop), and Node.js delivery (not Bun). We decoded and compared the vapi 1.2.1 payload against this one and found no code overlap.

Our honest assessment:

We cannot confirm this is the same actor you tracked in June 2026. The possibilities are:

• Same operator, newer/evolved toolkit generation (self-naming as "miasma" would be consistent)
• Different actor who happens to use the same name (less likely but possible)
• A fork or derivative of the Miasma toolkit that diverged significantly

The "Miasma" label in our report should be read as the attacker's self-described campaign name from the payload, not as a confirmed technical attribution to the campaign you documented. We've updated our internal notes to reflect this distinction.

Appreciate the pushback - this kind of cross-researcher validation matters.

[jonaslagoni]

Not sure its related but, probably linked to the spam attack too https://github.com/asyncapi/generator/pulls?q=is%3Apr+is%3Aclosed for the simple reason of moving focus 🤔

[LidorMachluf]

@raphabot We confirmed the next branch had no branch protection rules, so a single token with contents: write scope was sufficient to push directly with no review required. The commit 3eab3ec9 on next proves the attacker had write access - but the specific credential they used to authenticate that push (PAT, deploy key, SSH key, leaked workflow token) is unknown from our analysis.

The release workflow (release-with-changesets.yml) uses an org-level PAT (secrets.GH_TOKEN) which would grant cross-repo write access consistent with both repos being hit in the same hour - but we cannot confirm this was the specific credential used. That requires GitHub's audit log, which only the org owners and GitHub Security have access to.

The maintainers should engage GitHub Security directly for forensics on how the push was authenticated. That is the only path to a confirmed answer.

[derberg]

tokens are rotated, bots for now do not have rights to commit, also we do not allow PRs from not known contributors atm in this and community repo.

my guess for now is that issue might be https://github.com/asyncapi/generator/blob/master/.github/workflows/manual-netlify-preview.yml through https://github.com/asyncapi/generator/compare/47be3886e460107a4ea5ce88ad674a65724ac4a7..ff010ef38e1be1ffc4112c8903f43637ecbf4041 but that is not confirmed yet

unfortunately npm is not following up with our report to remove vulnerable versions - some reports were delayed also because they rate-limited me when I tried to report each vulnerability separately in the UI.....

[rami-wiz]

@derberg we break down the attack chain in https://www.wiz.io/blog/m-red-team-asyncapi-supply-chain-compromise-via-github-actions if it helps

The payload in template-production.md is a loader that fetches a payload from from rentry.co/elzotebo999 then executes it. Secrets were exfiltrated via rentry.co/elzotebo