• 發布單位:TWCERT/CC
• 更新日期:2026-06-26
• 點閱次數:133

知名網頁應用程式框架 TanStack 的 npm 套件近期遭到駭客組織 TeamPCP 發動名為「Mini Shai-Hulud」的大規模軟體供應鏈攻擊，攻擊者在短短幾分鐘內發布了 42 個 「@tanstack/*」套件的 84 個惡意版本。本次攻擊的惡意套件首次具備有效的 SLSA（軟體供應鏈安全框架）第3級來源證明，使其外觀與合法套件無異。該惡意軟體具備自我傳播能力，已迅速擴散至 Mistral AI、UiPath 與 OpenSearch 等 170 多個 npm 與 PyPI 套件，更導致知名 AI 企業 OpenAI 內部員工裝置遭入侵，部分原始碼專案庫遭未經授權存取。

根據 TanStack 官方發布的事後檢討報告，這次的攻擊之所以能成功，根本原因在於駭客將三個獨立的弱點串聯在一起，官方特別強調，這三項弱點「缺一不可」，單一弱點皆不足以構成此次的攻擊。以下是根據 TanStack 官方報告重新整理的三項弱點剖析：

1. 外部Pull Request（PR）可在主專案庫環境執行

官方的「bundle-size.yml」工作流程使用「pull_request_target」觸發條件處理外部Pull Request（PR）請求，並在主專案庫的工作流程環境下檢出與執行外部程式碼，使不受信任的可能接觸主專案庫的相關資源。儘管官方在設計工作流程時，曾試圖透過設定唯讀權限區分信任邊界，卻忽略兩個致命的機制盲點。首先，GitHub Actions 的快取機制在寫入快取時，使用的是執行器內部的Token，因此不受工作流程唯讀權限限制；其次，快取範圍是專案庫共享，表示主專案庫上下文中執行的外部PR請求程式碼，將能夠越權竄改並污染主專案庫的快取資料。

2. 低權限測試流程與高權限發布流程共用快取

駭客在外部PR請求中夾帶特定的惡意腳本（vite_setup.mjs），將惡意資料寫入pnpm的儲存目錄中，並使用與官方發布流程（release.yml）相同的快取金鑰。當該PR請求建置測試任務結束後，包含惡意程式的資料即被寫入 GitHub Actions 的共用快取中。遭植入惡意內容的快取可能持續保留於系統中，直到專案將其他合法程式碼合併至主分支，並觸發「release.yml」發布工作流程。執行過程中，「設定工具」步驟可能自動載入並還原該快取檔案，使惡意內容進入原具有較高信任權限的發布流程。

3. 發布流程授予 OIDC Token 權限，但缺乏足夠的執行環境隔離

為了能夠透過 OIDC 信任綁定在 npm 上發布套件，官方的「release.yml」發布工作流程宣告「id-token: write」權限，然而，這項權限卻遭到駭客濫用。當被投毒的快取在執行器上還原後，駭客潛伏的惡意二進制檔案便會在建置步驟中被觸發，這些惡意程式會主動尋找 GitHub Actions 執行器的工作處理程序，藉由讀取該程序的記憶體配置，直接從中提取出動態生成的 OIDC Token。取得OIDC Token後，惡意程式便越權直接向 npm 註冊表發送 POST 請求發布惡意套件，此舉完全繞過了官方工作流程中原先設定好的「發布套件」步驟。

此次供應鏈攻擊影響範圍甚大，不僅導致跨領域開源生態系淪陷，包含每週下載量破千萬的 「@tanstack/react-router」 在內的 42 個套件受害，惡意軟體入侵開發者裝置後，還會自動搜尋並利用受害者權限發布其他套件，使災情擴大至 「@mistralai」、「@uipath」、「@opensearch-project」等超過 170 個專案。在感染後，名為 「router_init.js」的惡意酬載會進行大範圍憑證竊取，全面搜刮 CI/CD 環境與開發者本機的機敏資料。這些資料並未傳送至傳統的 C2 惡意中繼站，而是隱蔽地透過點對點（P2P）資料外洩，經由去中心化的 Session 通訊網路進行端到端加密傳輸，使流量偽裝成一般的通訊軟體遙測數據。更具威脅的是，該惡意軟體內建系統刪除機制，會持續監控遭竊的 GitHub Token有效狀態；若偵測到Token已遭撤銷，便會立即觸發系統指令，將受害者的主目錄資料刪除。

TWCERT/CC 呼籲開發團隊與企業應立即檢視內部專案，並採取以下應變措施：

1. 清查受害範圍：立即檢查專案的 lockfile 與 CI 日誌，確認是否安裝受影響或遭竄改的版本套件。
2. 優先清除常駐程式：在撤銷任何外洩的Token之前務必先檢查macOS 或 Linux 系統中是否存在 gh-token-monitor 常駐程式並將其移除，以避免觸發惡意軟體的資料刪除機制。
3. 全面更換機敏憑證：請立即更換可能曝險在受感染環境中的所有憑證，包含 GitHub/npm Token、雲端供應商憑證、SSH 金鑰等。
4. 強化 CI/CD 與 OIDC 工作流程：嚴格審查 GitHub Actions，避免在處理來源不明或不受信任的Pull Request（PR）時，使用「pull_request_target」作為觸發條件，並禁止此類工作流程具備寫入快取的權限；此外，應落實 OIDC Token的最小權限原則，僅在需要發布套件的特定步驟授予權限。
5. 勿單一依賴 SLSA 證明：此次事件證明，具備 SLSA 來源證明的套件亦可能含有惡意程式碼。建議企業在導入套件時，應結合安裝時的行為監控與套件發布時間緩衝期（Cooldowns）機制，以多層次防禦降低供應鏈風險。