AsyncAPI 四套件遭落毒：合法 npm provenance 點解照樣失守
惡意版本已下架，但載入過套件嘅開發機同 CI runner 仲要查
呢宗 AsyncAPI 供應鏈攻擊發生喺 2026 年 7 月 14 日，唔係 8 月初先爆發。iThome 8 月 3 日報道事件時，五個惡意版本已經無法經 npm registry 取得，latest tag 亦已指返去乾淨版本。不過套件一旦入咗 lockfile、公司快取、build artifact 或開發機，從 registry 下架唔會自動清走，所以用 Node.js 跑 CI/CD、文件生成或 event-driven API 工具嘅團隊仲有手尾要跟。
四個套件、五個惡意版本
今次涉及四個套件、五個惡意版本，當中 @asyncapi/specs 有正式版同 alpha 版各一個：
| 套件 | 惡意版本 | 可回退嘅已知乾淨版本 |
|---|---|---|
@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；npm latest 而家係 1.0.0 |
@asyncapi/specs |
6.11.2、6.11.2-alpha.1 |
6.11.1 |
幾份研究都提到呢批套件合計每星期約有 290 萬次下載，數字主要來自 @asyncapi/specs。呢個只代表平時嘅潛在接觸面，唔等於 290 萬部機中招，更唔係已確認受害者數目。 真正要追嘅係事故時段有邊個環境解析到上述版本，跟住有冇載入過套件。
圖片：Wiz Research
pull_request_target 點樣變成入場券
pull_request_target 本身係 GitHub Actions 畀專案處理外來 pull request 嘅高權限模式，例如自動加標籤或留言。佢會喺原專案嘅可信環境執行，可以接觸 secrets 同有寫入權限嘅 token。AsyncAPI 出事嘅 workflow 卻 checkout 咗提交者控制嘅程式碼再執行，變相畀陌生人帶自己嘅指令入高權限 runner。
GitHub 紀錄顯示，有貢獻者早喺 4 月 29 日用 proof of concept 示範問題，5 月 17 日再提出拆開可信同不可信工作嘅修補方法。修補未合併，58 日後攻擊者一次過開咗 37 個 pull request，其中一個藏住混淆程式碼。PR 冇合併，但 workflow 已經跑完，asyncapi-bot 嘅高權限 PAT 亦落入對方手上。
官方發布、合法簽署，入面一樣可以有毒
攻擊者用偷返嚟嘅 PAT 直接改動連住發布流程嘅 branch，AsyncAPI 自己嘅 GitHub Actions 跟正常設定啟動，再用 npm OIDC trusted publisher 推出套件。JFrog 核對過，五個版本都有有效 provenance，資料亦正確指向 AsyncAPI 嘅 repository、commit 同發布 workflow。
呢點值得拆清楚：provenance 證明「邊條 pipeline 整出呢個套件」，冇判斷「觸發 pipeline 嗰次改動係咪可信」。 當 source branch、bot token 或發布 workflow 已經俾人控制，provenance 一樣會顯示簽署有效，但唔代表套件安全。iThome 報道提到攻擊者取得 npm 發布權杖；Wiz 同 JFrog 重組嘅流程就顯示，主要憑證係 GitHub PAT，之後由官方 OIDC 發布，未見一定要偷長效 npm token。
裝過未必啟動，載入過就要當成事故
惡意碼冇靠常見嘅 preinstall 或 postinstall script，而係等程式 import 或 require 套件先郁手。即係 npm install --ignore-scripts 都未必幫到你；安裝後一直冇載入，風險會低一截，但 build、文件生成、測試同間接 dependency 都可能靜靜載入佢，單靠開發者記憶去判斷唔穩陣。
Wiz 發現載入器會另開 Node.js process，經 IPFS 下載第二階段程式，再寫到 Linux 嘅 ~/.local/share/NodeJS/sync.js、macOS 嘅 ~/Library/Application Support/NodeJS/sync.js，或者 Windows 嘅 %LOCALAPPDATA%\NodeJS\sync.js。研究亦列出 miasma-monitor.service、C2 IP 85.137.53.71、IPFS 流量同異常 detached Node.js process 等線索。惡意程式具備遙距指令、檔案操作同憑證蒐集能力，但唔同團隊對 Miasma、Mini Shai-Hulud 同相關攻擊者嘅關係未有一致結論，暫時唔適合寫死歸因。
中過版本，應該點處理
先隔離有關開發機同 runner，再用乾淨裝置改憑證。 搜尋 package-lock.json、pnpm-lock.yaml、yarn.lock、dependency cache、container layer 同舊 build artifact，確認五個版本曾經去過邊度；再用 process、檔案、網絡同 CI job 紀錄，分清只下載過，抑或真係載入過。共用或可重用嘅 runner 最好重新建立，唔好淨係刪 sync.js 就當處理完。
任何載入過惡意版本、或者紀錄不足以排除執行嘅環境，都要當 secrets 可能外洩。由乾淨裝置撤銷同重發 GitHub PAT、GitHub App／Actions secrets、npm token、SSH key、AWS 或其他雲端 access key，亦要檢查瀏覽器儲存嘅密碼同 session。跟住翻查 GitHub audit log、npm 發布紀錄、雲端 API 活動同 repository branch，睇吓有冇陌生 push、workflow、登入或新憑證。
最後鎖定上表嘅乾淨版本，刪走舊 dependency cache，再由可信來源重建。8 月 3 日核對 npm registry 時，五個惡意版本已無法解析，不過自動跟 latest 只解決下一次安裝，舊 lockfile、內部鏡像同已建好嘅 container 仲要逐一清。維護 GitHub Actions 嘅團隊亦應搜尋 pull_request_target，凡係會 checkout 或執行外來 PR 內容嘅 workflow，都要拆開權限、收窄 token，同保護連住自動發布嘅 branch。
參考來源
- iThome — AsyncAPI遭NPM供應鏈攻擊，駭客利用錯誤配置的GitHub Actions得逞，發布惡意套件 — original report
- Wiz：AsyncAPI Supply Chain Compromise via GitHub Actions — 提供攻擊時間線、五個惡意版本、載入路徑、IOC 同歸因限制。
- JFrog：Miasma Worm Returns to npm — 分析 payload，同解釋 OIDC trusted publisher 及有效 provenance 點解照樣失守。
- GitHub Docs：Secure use reference — GitHub 官方對 pull_request_target、外來程式碼同 secrets 風險嘅指引。
- AsyncAPI Generator PR #2078 — 專案原始紀錄，確認 4 月 29 日已有 proof of concept 示範 workflow 問題。
- npm Registry：@asyncapi/generator — 核對套件現時 dist-tag，同確認惡意版本已無法經 registry 解析。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
