OpenAI 證實兩臺員工電腦遭 TanStack 供應鏈攻擊波及，ChatGPT、Codex macOS 用戶須在 6/12 前更新

5 月 11 日，駭客組織 TeamPCP 以 TanStack 為跳板發動大規模 npm 供應鏈攻擊，OpenAI 兩臺員工裝置受波及，受影響平台涵蓋 iOS、macOS、Windows 的程式碼簽名證書，macOS 用戶必須在 2026 年 6 月 12 日前更新應用程式，逾期將無法啟動。
（前情提要：OpenClaw「小龍蝦」爆雙重危機！axios 供應鏈藏投毒後門、MEDIA 漏洞波及全球 17 萬案例）
（背景補充：Ledger警告「別互動鏈上合約」：JavaScript套件NPM遭駭，數十億裝置恐感染惡意程式碼）

本文目錄

一個沒人注意的開源函式庫，結果讓全球最大的 AI 公司暴露在風險之中。台灣時間 2026 年 5 月 12 日清晨，，駭客組織 TeamPCP 在短短六分鐘內完成攻擊：42 個屬於 @tanstack 名稱空間的 npm 套件遭到毒化，84 個惡意版本被推送至 npm 倉庫。

@tanstack/react-router 每週下載量約 1,200 萬次，整個攻擊波及超過 170 個 npm 與 PyPI 套件，累計下載次數超過 5.18 億次。受波及的不只是開發者，還有 OpenAI、Mistral AI、Guardrails AI 等 AI 公司的內部環境。

六分鐘的攻擊，OpenAI 兩臺裝置淪陷

OpenAI 公告確認，公司環境中有兩臺員工裝置遭到此次攻擊影響。在這兩名員工可存取的有限程式碼倉庫子集中，調查發現了與惡意軟體行為一致的活動：未經授權的存取，以及以憑證為目標的外洩行動。

所幸確認遭竊的範圍相對有限：只有部分憑證材料從這些倉庫成功外洩，其他程式碼與資訊未受影響。

調查委託了第三方數位鑑識與事件響應公司介入，未發現客戶資料或智慧財產權受波及的證據，也未識別到憑證被濫用或攻擊者在事後持續存取的跡象。

不過問題在於，這些程式碼倉庫中恰好存有產品的程式碼簽名證書（code signing certificate，白話來說就是向作業系統證明這個軟體是我發布的合法印章），涵蓋 iOS、macOS 與 Windows 三個平台。這直接觸發了後續一系列預防性措施。

macOS 用戶需主動更新

OpenAI 正在輪換所有受影響平台的程式碼簽名證書，並重新以新證書簽名發布所有應用程式。Windows 與 iOS 用戶無需採取任何行動。macOS 用戶則必須主動更新。

時間節點是 2026 年 6 月 12 日之前。一旦舊證書在這天完全撤銷，macOS 的安全保護機制將阻止使用舊證書簽名的應用程式被下載或啟動。以下是使用舊證書簽名的最後版本，這些版本在截止日後將無法正常運作：

ChatGPT Desktop 1.2026.125
Codex App 26.506.31421
Codex CLI 0.130.0
Atlas 1.2026.119.1

這次事件的核心教訓，OpenAI 自己說得直接：攻擊者越來越多地針對共享的軟體依賴項和開發工具，而非任何單一公司。現代軟體建立在深度互聯的開源函式庫、套件管理器和 CI/CD 基礎設施生態系統之上——上游一個漏洞，可以在組織之間廣泛且迅速地傳播。

你的公司有多少個像 TanStack 一樣「所有人都在用、沒人在管」的依賴項，沒有人說得清楚。

這次攻擊為何特別難防

TeamPCP 的手法讓這次事件在安全史上留下一個記錄：這是首次有人成功發布帶有有效 SLSA Build Level 3 provenance attestations 的惡意套件。

解釋一下這意味著什麼。SLSA（Supply-chain Levels for Software Artifacts）是目前最受認可的軟體供應鏈安全驗證標準，Level 3 要求套件在可重現、有記錄的建置環境中生成，並附上可驗證的來源證明。

簡單來說：這張「安全認證標章」過去被認為足以排除惡意投毒的可能性，但這次不行了。

攻擊者的方式是利用 GitHub Actions 中三個漏洞的組合，毒化 pnpm 快取（pnpm 是 JavaScript 生態中廣泛使用的套件管理工具），再透過 OIDC token（一種不需要儲存長效金鑰的身份驗證機制）在不竊取 npm 帳號密碼的情況下，直接以合法身份發布惡意套件。整個流程走的是正規管道，簽名是真的，來源證明也是真的，只有套件內容是假的。

惡意軟體植入後，會在開發者機器上安裝一個名為 gh-token-monitor 的守護程式，可觸發 rm -rf ~/（刪除用戶目錄下所有檔案的指令），且守護程式在 24 小時後自動停止，增加取證難度。根據 Socket.dev 的攻擊分析報告，這波攻擊的規模與技術複雜度都屬罕見。

OpenAI 此前也曾在 axios 事件後加速部署安全控制，包括強化 CI/CD 管道中敏感憑證的保護，以及部署帶有 minimumReleaseAge 等控制措施的套件管理器設定。後者的邏輯是讓新發布的套件「等待一段時間再被採用」，減少零時差投毒的傷害視窗。