2026年5月11日，流行的開源項目TanStack遭遇了一次高度複雜的供應鏈攻擊，該事件不僅影響了TanStack自身，還波及了包括Mistral AI、UiPath、OpenAI和Grafana Labs在內的160多個npm和PyPI軟件包，總計發佈了400多個惡意版本。此次攻擊由名為TeamPCP的威脅組織發起，並被命名為“Mini Shai-Hulud”，它深刻揭示了現代軟件開發中開源生態系統的脆弱性，併為Web3領域的安全防護敲響了警鐘。
TanStack供應鏈攻擊事件回顧
此次攻擊發生在2026年5月11日UTC時間19:20至19:26之間，攻擊者在短短六分鐘內，向42個@tanstack命名空間下的npm包發佈了84個惡意版本。值得注意的是，攻擊者並未直接竊取npm憑證或通過網絡釣魚獲取維護者賬户，而是利用了GitHub Actions工作流中的一系列漏洞。
- 漏洞鏈利用： 攻擊鏈涉及三個關鍵的GitHub Actions漏洞：
pull_request_target工作流配置不當、GitHub Actions緩存投毒以及運行時OpenID Connect (OIDC) 令牌提取。攻擊者首先創建了TanStack/router倉庫的一個偽裝分支，並提交了一個包含惡意負載的拉取請求。由於pull_request_target工作流的配置問題，該拉取請求在具有基礎倉庫權限的環境中執行，從而允許攻擊者向GitHub Actions緩存中注入惡意內容。隨後，當合法的維護者合併代碼並觸發發佈工作流時，被投毒的緩存被恢復，攻擊者便能從GitHub Actions運行器進程內存中直接提取OIDC令牌。 - 惡意負載與傳播： 此次攻擊的惡意負載被稱為“Mini Shai-Hulud”，它是一個自我傳播的憑證竊取蠕蟲。一旦被感染的軟件包被安裝，惡意代碼便會在npm生命週期鈎子中執行，竊取包括GitHub令牌、npm令牌、AWS、GCP、Azure憑證、Kubernetes服務賬户令牌、HashiCorp Vault令牌、SSH密鑰和環境變量在內的多種敏感信息。該蠕蟲還會識別受害者擁有發佈權限的其他npm包，修改這些包的存檔以注入相同的惡意依賴，提升版本號，並使用竊取的憑證發佈新的受感染版本，從而實現自我傳播。
- 隱蔽性與影響： 此次攻擊的危險之處在於，惡意軟件包是通過TanStack的合法發佈管道發佈的，並帶有有效的npm出處證明（provenance attestations）。這意味着，這些惡意版本在標準驗證方法下與合法版本幾乎無法區分，甚至通過了SLSA出處檢查和有效簽名證書的驗證。 攻擊迅速蔓延，導致OpenAI內部源代碼倉庫的憑證材料被竊取，Grafana Labs的代碼庫被下載，並影響了多個高下載量的軟件包，如
@tanstack/react-router（每週下載量超過1270萬次）。
開源生態系統的安全警鐘
TanStack事件凸顯了現代軟件供應鏈日益增長的複雜性和脆弱性，併為整個開源生態系統敲響了警鐘：
- CI/CD管道成為主要攻擊面： 攻擊表明，攻擊者不再僅僅針對源代碼倉庫或憑證，而是將目光投向了持續集成/持續部署（CI/CD）管道本身，包括緩存、工作流權限和依賴解析系統。構建管道已成為現代軟件開發中的主要攻擊面。
- 傳統安全措施的侷限性： 即使項目啓用了雙因素認證（2FA）並遵循了SLSA出處驗證等最佳實踐，也可能無法抵禦這種利用CI/CD系統信任鏈的複雜攻擊。
- 信任邊界的模糊： 攻擊利用了GitHub Actions中跨“fork-to-base”信任邊界的漏洞，使得來自fork倉庫的惡意代碼能夠在基礎倉庫的權限下執行，這模糊了傳統上對外部貢獻的信任邊界。
- “蠕蟲式”傳播的威脅： 惡意負載的自我傳播能力意味着一個初始的妥協可能迅速擴散到整個依賴圖，影響成百上千的下游項目，造成廣泛而深遠的損害。
Web3領域的防護之道
Web3項目因其管理着鉅額數字資產的特性，成為供應鏈攻擊的特別有吸引力的目標。供應鏈攻擊可能直接導致用户資金被盜、私鑰泄露或惡意合約部署，其後果往往是不可逆轉的。 因此，Web3項目必須從以下幾個方面加強防護：
1. 加強開發流程與CI/CD安全
- 嚴格的GitHub Actions配置： 仔細審查所有GitHub Actions工作流，特別是使用
pull_request_target觸發器的工作流，確保它們不會在不安全的權限下執行來自fork倉庫的代碼。 - 憑證管理與輪換： 對CI/CD管道中使用的所有敏感憑證（如雲服務密鑰、API令牌、SSH密鑰）進行嚴格管理和定期輪換。
- 緩存安全： 實施嚴格的緩存策略，避免在CI/CD環境中共享或重用可能被投毒的緩存，尤其是在處理來自不受信任來源的代碼時。
- 出處驗證與額外安全檢查： 儘管SLSA出處驗證被繞過，但仍應將其作為基礎安全措施。同時，部署額外的安全軟件來驗證新軟件包的出處和完整性，例如實施
minimumReleaseAge等包管理器配置，以減少新發布惡意包的即時風險。
2. 依賴管理與軟件物料清單（SBOM）
- 全面的依賴審計： 定期對項目所有第三方依賴進行審計，包括直接和間接依賴，確保其來源可靠且無已知漏洞。
- 生成與維護SBOM： 為所有Web3應用生成並維護軟件物料清單（SBOM），清晰記錄所有組件及其版本，以便在發現漏洞時能夠迅速識別受影響的範圍。
- 依賴冷卻策略： 採用依賴冷卻策略，例如阻止新發布的軟件包立即安裝，以減少對快速移動攻擊的暴露。
3. 代碼完整性與簽名基礎設施保護
- 代碼提交簽名： 強制要求所有代碼提交都進行GPG簽名，並驗證簽名，以確保代碼的完整性和來源可信。
- 保護簽名基礎設施： 對用於代碼簽名和發佈二進制文件的基礎設施進行最高級別的保護，防止攻擊者生成合法簽名的惡意軟件。
- 靜態與動態代碼分析： 在CI/CD流程中集成靜態應用安全測試（SAST）和動態應用安全測試（DAST）工具，檢測潛在的漏洞和惡意代碼。
4. 開發者教育與用户防護
- 安全意識培訓： 對開發團隊進行Web3特有的供應鏈攻擊向量培訓，例如惡意npm包如何竊取私鑰、受損的開發工具如何修改交易參數以及針對包維護者的社會工程學攻擊。
- 用户權限限制： 建議用户在與DApp交互時限制授予的權限，並對高風險操作進行多重驗證。
- 硬件錢包與資產隔離： 鼓勵用户使用硬件錢包存儲長期資產，並將不同風險級別的資產進行隔離，以降低潛在損失。
TanStack供應鏈攻擊再次證明，Web3的安全不僅僅侷限於智能合約本身，而是貫穿於整個軟件開發生命週期的每一個環節。只有全面提升供應鏈安全意識和防護能力，Web3生態系統才能更好地抵禦日益複雜的威脅。
