SAP @cap-js 與 mbt npm 套件遭植入惡意版本(Mini Shai-Hulud):安裝後可能竊取登入金鑰並自我擴散

影響範圍

這不是程式寫錯的漏洞,而是 SAP 官方套件被換成了惡意版本(CWE-506,內嵌惡意程式碼)。同一天有兩起相關但不同的入侵:三個 @cap-js 套件(GHSA-pvw4-cvr4-97p8 / CVE-2026-46421),以及 mbt(另列為 MAL-2026-3179,不在這個 CVE 範圍內)。

規模參考:Socket 估計每週下載量約為 db-service 26 萬、sqlite 25 萬、mbt 5.2 萬、postgres 1 萬;SafeDep 估計四個套件每月合計約 120 萬次安裝。

原理

攻擊者怎麼拿到發布權限。

• @cap-js:SAP 在 PR #1592 說明,未授權者推送惡意提交劫持了發布 workflow,並觸發未經授權的 npm 發布,而且 npm 發布前沒有人工核准。SAP 沒有說明這次發布用的是受信任發布(OIDC)還是某個 npm token,研究者的說法不一:
  • StepSecurity 與 SafeDep 說攻擊者控制了一位 SAP 開發者的 GitHub 帳號,修改發布 workflow 讓它從非主分支執行,再用 CI 工作的 OIDC 身分透過受信任發布向 npm 換取發布憑證,把憑證編碼後印到建置紀錄,再拿去發布。
  • Snyk 依 npm registry 資料指出,四個惡意版本(含三個 @cap-js)都由 cloudmtabot 帳號發布;OSV 的 MAL-2026-3178、MAL-2026-3179 也寫由「cloudmtabot@gmail.com」發布。
  • SAP 沒有證實或否認哪一種,本頁無法判定。
• mbt:依 StepSecurity,1.2.48 用的是 cloudmtabot 帳號的長期 npm token,mbt 從未使用受信任發布。token 如何外洩尚未確認。BleepingComputer 引述資安工程師 Adnan Khan,說 SAP 的 npm 發布流程可能有 npm token 經設定錯誤的 CircleCI 工作外洩,但沒有指明是哪個套件;是否就是 mbt 的 token,目前沒有來源證實。

關鍵的設定缺口。 npm 的受信任發布(trusted publishing)會把發布權綁定到某個組織、某個 repo 和一個確切的 workflow 檔名;GitHub 部署環境(可以要求核准)則是選用。SafeDep 與 StepSecurity 指出,這裡的信任範圍沒有限定受保護分支或需核准的環境,所以攻擊者在自己的分支上執行 workflow,也能換到發布憑證。SAP 實際的設定內容本頁無法確認;如果 Snyk 與 OSV 所說的 cloudmtabot 發布才是實情,這個設定缺口就不是這次的直接原因,但 SAP 確實在事後加上了發布前的人工核准。

有問題的思路(概念示意,不是 SAP 的實際設定):

# npm 信任:這個 repo + release.yml 就可以發布
# 沒有綁定部署環境 → 任何分支上的 release.yml 都能換到發布憑證
jobs:
  publish:
    permissions:
      id-token: write

修好的思路:

# npm 信任:這個 repo + release.yml + 環境 "npm-release"
# 環境規則設在 repo 設定裡(改 workflow 檔改不到):
#   只允許受保護的 main 分支、需要維護者核准
jobs:
  publish:
    environment: npm-release
    permissions:
      id-token: write

重點是:只在 workflow 檔裡寫「只在 main 執行」並不夠,因為攻擊者本來就能改那個檔案;限制必須放在攻擊者改不到的地方,例如部署環境的保護規則。

惡意程式做了什麼。 官方公告只說它會蒐集憑證並「嘗試自我擴散」;以下細節來自 StepSecurity、SafeDep、Snyk 等研究者的分析。

1. 惡意版本在正常套件內容之外多了 setup.mjs 與 execution.js,並修改了 package.json。依 SafeDep,三個 @cap-js 惡意版本沒有 npm provenance 證明,而前一版正式版本有;mbt 的所有版本在 npm registry 上本來就沒有 provenance,所以這一點只適用於 @cap-js。
2. setup.mjs 以 preinstall 腳本執行,裝下去就會跑,不需要 import。它下載正當的 Bun 執行環境,用來執行約 11 MB 的混淆程式(OSV 寫 11.1 MB,StepSecurity 寫 11.6 MB)。
3. 竊取 npm/GitHub token、SSH 金鑰、AWS/Azure/GCP 憑證與秘密管理服務存取、Kubernetes 設定、CI/CD 秘密,另外還有 AI 工具設定與加密錢包。在 GitHub Actions 上會直接從 runner 程序的記憶體讀取秘密,繞過紀錄遮罩。
4. 資料加密後提交到受害者帳號下新建的公開 repo,描述為「A Mini Shai-Hulud has Appeared」。SafeDep 另外描述了一個 HTTPS 指揮伺服器,各家報告的細節不一致。
5. 自我擴散:依 StepSecurity 的逆向分析,它會用偷來的 npm token 發布受害者能發布的其他套件的感染版,並用對 repo 有寫入權限的 GitHub token 提交後門檔案(要注入 workflow 還需要有 workflow 權限的 token)。Snyk 發文時表示,只觀察到原本四個套件受害。

AI 程式代理被拿來當後門。 依 StepSecurity 與 SafeDep,蠕蟲拿到有權限的 GitHub token 時會提交 .claude/settings.json(含 SessionStart hook)與 .vscode/tasks.json(開啟資料夾時執行),讓開發者一打開專案或啟動 AI 程式代理,惡意程式就再跑一次。提交作者顯示為「claude」、簽章未驗證,看起來像例行的 AI 助手更新。StepSecurity 認為這是最早用這種方式濫用 AI 代理設定的供應鏈攻擊之一。攻擊者也推送了模仿 Dependabot 名稱的分支,裡面的 workflow 用來匯出 repo 秘密。StepSecurity 報告指出程式有「遇到俄語系統就停止」的機制。

時間軸

延伸閱讀

• 編號更正。 本頁輸入的事件紀錄寫著「沒有 CVE」,但 GitHub 已為 GHSA-pvw4-cvr4-97p8 指派 CVE-2026-46421。它仍然不在 CISA KEV 清單中。這個 CVE 只涵蓋三個 @cap-js 套件,mbt 是另一起、另一種手法的入侵。
• 評分。 唯一的分數是 GitHub(CNA)給的 CVSS 4.0 9.3(嚴重);NVD 沒有自行評分(Deferred),也找不到 CVSS 3.x 分數。CVE 紀錄中 CISA 的 SSVC 欄位寫著 Exploitation「none」,這只是資料欄位,不代表攻擊沒發生:研究者確實觀察到它在外擴散。
• 日期基準。 本頁的揭露日期取 2026-04-29,也就是第一個惡意版本(mbt 1.2.48,09:55 UTC)出現在 npm 的日子;本站對供應鏈入侵事件一律以惡意版本出現日為準。維護者公告(05-14)與 CVE(07-15)都比這晚。
• 來源間的差異。 @cap-js 惡意版本的發布方式:SAP 只說劫持的 workflow 觸發了未經授權的 npm 發布;StepSecurity 與 SafeDep 說是透過受信任發布(OIDC)換到憑證,Snyk 與 OSV 說是由 cloudmtabot 帳號發布。@cap-js/sqlite 的修補版本:維護者公告與 CVE 描述寫 2.4.0 以上,GitHub 全域資料庫與 OSV 的結構化資料寫 2.3.0,但 npm 上從未出現 sqlite 2.3.0。惡意 payload 大小有 11.1 MB 與 11.6 MB 兩種說法。資料外送管道,StepSecurity 說是 GitHub API,SafeDep 描述了 HTTPS 指揮伺服器。
• 系列背景。 Shai-Hulud 第一波(2025 年 9 月)是透過安裝腳本自我複製的 npm 蠕蟲;第二波(2025 年 11 月,Shai-Hulud 2.0)改用 preinstall 與 Bun 載入器,Unit 42 統計超過 25,000 個惡意 repo。StepSecurity 稱本次為第三波。
• 歸因只是研究者評估。 Socket 以中等信心連結到 TeamPCP(依據包括共用的加密方式、俄語系統停止機制、濫用 GitHub 當指揮通道),StepSecurity 則指向東歐或俄羅斯的操作者。官方沒有歸因。
• 檔案雜湊與更多網路指標 請見 StepSecurity 的報告;官方公告沒有公布這些內容,本頁不轉載。
• 相關弱點類型:CWE-506(內嵌惡意程式碼)。