Nx Console 18.95.0 遭植入惡意程式:VS Code 擴充套件自動更新後竊取開發者憑證

影響範圍

這不是程式寫錯造成的漏洞,而是有人拿到發布權限後,故意發布了一個帶毒的版本。CWE-506(內嵌惡意程式碼)就是描述這種情況。

各市集的上架時間:VS Code Marketplace 約 12:30–12:48 UTC,Open VSX 約 12:33–13:09 UTC。官方數字是 Microsoft Marketplace 28 次安裝、Open VSX 41 次下載(21 個不同 IP),但 Nx 自己的分析記錄到約 6,000 次啟用;廠商解釋兩者計算的東西不同(安裝次數與啟用次數)。

原理

Nx 的事後檢討把這起事件拆成四個串在一起的失誤:

1. 上游套件先被入侵。 2026-05-11,攻擊者發布了 42 個 @tanstack/* npm 套件的惡意版本(CVE-2026-45321)。
2. 安全設定默默失效。 一名 Nx 貢獻者在另一個專案做例行安裝。那個專案設了 7 天的「最短發布時間」,本來會跳過太新的套件;但這個設定要 pnpm 10.16 以上才支援,專案卻鎖在 pnpm 10.14,舊版遇到不認得的設定直接忽略。結果裝到了才發布 77 分鐘的惡意 TanStack 版本。
3. CLI token 沒有保護。 這名貢獻者的 GitHub CLI token 放在本機程式拿得到的地方:設定檔 ~/.config/gh/hosts.yml、執行 gh auth token,或執行中 gh 程序的記憶體。事後檢討說還沒確定惡意程式走的是哪一條,只知道它執行後 74 秒內就取得並使用了這個 token。攻擊者從 5 月 11 日用到 16 日,推送 commit 並刪除 workflow 執行紀錄。
4. 一個人就能發布。 和 Nx 其他產品不同,發布 Nx Console 不需要第二個人核准。

5 月 18 日,惡意的 18.95.0 被上傳;Marketplace 記錄的上傳者就是那位被入侵的貢獻者。官方公告說偷來的憑證讓攻擊者能以貢獻者身分執行 workflow,但確切用了哪個 token、哪條管道,官方沒有細說。

根據 StepSecurity 的分析,擴充套件主程式被塞入一小段載入器。擴充套件一啟動(例如打開工作區),載入器就從攻擊者推進官方 nrwl/nx 程式庫的「孤兒 commit」抓取套件,安裝 Bun 執行環境,再執行高度混淆的惡意程式。重點是:惡意程式來自專案自己的可信程式庫,而不是明顯可疑的網域。

廠商確認的惡意行為: 蒐集 Vault token、Kubernetes 與 AWS IAM 認證、npm .npmrc token 與 npm OIDC token 交換、AWS 執行個體中繼資料、Secrets Manager、SSM 與 Web Identity token、GitHub token 與 Actions secrets、程序記憶體、1Password CLI 內容(只在當時已登入 op CLI 的情況下)、私鑰、連線字串、GCP 與 Docker 憑證;透過 HTTPS、GitHub API 與 DNS 傳出;在 Linux 上嘗試寫入 sudoers 以長期駐留。

只有 StepSecurity 提到的行為(第三方): 讀取 Claude Code 設定檔 ~/.claude/settings.json、在 Linux 掃描程序記憶體、傳出前先加密、在 macOS 安裝每小時執行並透過 GitHub 搜尋接收簽章指令的 Python 後門,以及能產生 Sigstore/SLSA 來源證明,讓偷來的 npm token 發布看起來簽章有效的套件。

有問題的發布流程(概念示意,不是 Nx 的實際設定):

# 任何有寫入權限的貢獻者觸發,就直接發布到市集
publish:
  steps:
    - run: publish-extension   # 沒有第二人核准

修好的思路:

# 發布工作綁定一個需要審核的 environment
publish:
  environment: release        # 需兩位管理者核准,且核准者不能是觸發者
  steps:
    - uses: some/action@<完整 commit SHA>   # Actions 釘選到確切 SHA
    - run: publish-extension

另一個教訓是「設定寫了不代表生效」:像最短發布時間這類保護,要確認你實際跑的工具版本支援它,否則可能被默默忽略。

時間軸

延伸閱讀

• 評分差異: 本頁標示的 9.8 分採用 NVD 的 CVSS 3.1 評分;GitHub(CNA)給的是 CVSS 4.0 的 9.3 分。兩者都標示不需使用者操作,符合「自動更新就會中招」的情況。GitHub 公告頁面顯示時沒有列 CWE 與分數,但 GitHub 送出的 CVE 紀錄有 CWE-506 與 9.3。
• 日期與時長不一致: CVE/NVD 描述寫 5 月 19 日,其他所有來源寫 5 月 18 日,本頁採用 5 月 18 日。VS Code Marketplace 的上架時長也有兩種說法:GHSA 公告與 CVE 紀錄寫 12:30 上架、12:48 下架,約 18 分鐘;Nx 事後檢討的時間軸寫 12:47 下架,是上傳後約 17 分鐘、12:36 收到通知信後約 11 分鐘,但同一篇開頭的摘要寫套件「上架約 11 分鐘」,StepSecurity 也引官方公告寫約 11 分鐘。來源沒有說明差異的原因(例如上傳時間是否等於可下載的時間),本頁兩種都列出。
• 勒索軟體標記: CISA KEV 紀錄把「已知用於勒索軟體活動」標為 Known。本頁照實轉述這是 CISA 的分類;我們讀到的來源都沒有把勒索軟體和 Nx Console 事件直接連起來,只有 Tenable 與 Snyk 轉述的「TeamPCP 與 Vect 勒索軟體集團合作」說法(Snyk 註明出自 Unit 42 依 BreachForums 公告所做的記錄),而 SANS 報告 Vect 的外洩網站到 6 月初仍無動靜。
• GitHub 事件: GitHub 表示攻擊者的說法和調查結果「方向一致」,沒有證據顯示內部程式庫以外的客戶資料受影響;它輪替了秘密與 GitHub Enterprise Server 簽章金鑰,GHES 管理者需要輪替 GPG 金鑰才能安裝之後的更新。GitHub 沒有指名攻擊者。
• 更大的攻擊活動: 資安廠商把上游 TanStack 事件歸為「Mini Shai-Hulud」蠕蟲活動,並歸因於 TeamPCP;但 TanStack 公告本身沒有命名,Unit 42 指出蠕蟲原始碼已在 5 月 12 日公開,SANS 也認為後續波次的歸因並不明確。各家對攻擊波次的算法也不同。Nx Console 惡意程式本身沒有來源描述它會像蠕蟲一樣擴散。
• 簽章不等於安全: 上游 TanStack 套件帶有有效的 SLSA Build Level 3 來源證明;有效簽章只能證明是哪條管線建出來的,不能證明程式無害。
• AI 相關: StepSecurity 指出這個惡意程式會讀取 Claude Code 設定檔,Nx 的事後檢討則完全沒有提到 AI。
• StepSecurity 稱這是一年內第二起針對 Nx 的供應鏈攻擊(前一起是 2025 年 8 月的 npm 事件),本頁未對照一手來源確認。
• 無法確認:18.96 到 18.99 為何被跳過;JetBrains 外掛是否受影響。