PyTorch Lightning遭供應鏈投毒：3萬星項目如何被攻破

4月30日，兩個看似尋常的版本更新悄然登上Python包索引倉庫。數小時后，全球數萬名AI開發者的機器上，一個隱藏的運行時目錄開始自動下載11MB的混淆代碼——而這一切，只需要一行import lightning。

事件現場：惡意版本如何潛伏

被污染的版本號是2.6.2和2.6.3。根據Aikido Security、OX Security、Socket及StepSecurity的聯合分析，這兩個版本于2026年4月30日同日發布，目前已被PyPI管理員隔離。

攻擊手法并不復雜，但足夠隱蔽。Socket的描述很直接：「惡意包包含一個隱藏的_runtime目錄，內含下載器和一個經過混淆的JavaScript載荷。」

整個執行鏈在lightning模塊被導入時自動觸發，無需用戶任何額外操作。這意味著開發者按照慣例安裝、導入，攻擊就已經完成。

具體路徑是這樣的：Python腳本"start.py"首先下載并執行Bun JavaScript運行時，隨后用這個運行時加載11MB的混淆載荷"router_runtime.js"。目標很明確——全面竊取憑證。

人物動作：攻擊者的雙重滲透策略

攻擊者沒有止步于單點突破。從竊取的憑證中，GitHub令牌會被單獨拎出來驗證，驗證接口是api.github.com/user。確認有效后，這些令牌被用于向最多50個分支注入蠕蟲式載荷——每個令牌能寫入的倉庫，每個倉庫最多50個分支。

Socket補充了一個關鍵細節：「操作是upsert模式：創建尚不存在的文件，靜默覆蓋已存在的文件。」沒有預先檢查現有內容。每一次被污染的提交，作者身份都被硬編碼為Anthropic的Claude Code——一個精心設計的偽裝。

但這只是第一層。攻擊者還埋設了npm傳播通道：修改開發者本地的npm包，在package.json中植入postinstall鉤子來調用惡意載荷，提升補丁版本號，重新打包.tgz文件。如果開發者不慎從本地環境發布這些被篡改的包，惡意代碼就會進入npm，進而感染下游用戶系統。

兩條路徑，一條針對Python生態，一條針對Node生態，彼此獨立又相互放大。

背后邏輯：供應鏈攻擊的"無感知"設計

PyTorch Lightning的定位很清晰——為PyTorch提供高層接口的開源框架。GitHub上超過31,100顆星，說明它在AI開發者中的滲透率。這種"基礎設施型"項目的特點是：被依賴得多，被審查得少。

攻擊者選擇它的邏輯也很清晰。不是因為它代碼質量差，恰恰相反——是因為它足夠主流、足夠被信任、足夠"理所當然"地出現在requirements.txt里。

整個攻擊鏈的設計都在降低被發現概率：

自動觸發，消除人為交互環節；混淆載荷，增加靜態分析難度；硬編碼身份偽裝，讓惡意提交看起來像是正規AI工具的行為；雙渠道傳播，即使Python端被發現，npm端可能仍在擴散。

更微妙的是版本號策略。2.6.2和2.6.3是連續的補丁版本，符合日常更新節奏。開發者看到小版本號變動，通常不會警覺。

項目維護方的回應目前停留在調查階段。「我們已知曉該問題并正在積極調查」，這是官方聲明。Lightning在另一份公告中承認，「受影響版本引入了與憑證收集機制一致的功能」，但確切根因仍在排查。現有跡象指向GitHub賬戶被入侵。

行業影響：信任模型的系統性壓力

這次事件與本周三針對SAP相關npm包的Mini Shai-Hulud供應鏈攻擊被評估為同一活動的延伸。攻擊者正在跨語言、跨平臺地尋找高影響力節點。

對開發者的即時影響很明確：需要封鎖2.6.2和2.6.3版本，如已安裝則移除，降級至最后一個已知干凈版本2.6.1，并輪換所有可能暴露的憑證。

但更深層的沖擊在于開發流程本身。postinstall鉤子的濫用、本地包的靜默篡改、版本號的自動遞增——這些原本用于提升效率的機制，正在被武器化為傳播工具。一個不小心的npm publish，就可能讓自己成為攻擊者的分發節點。

PyPI的隔離動作是事后止損。從4月30日發布到被隔離，窗口期內的下載量、實際感染范圍，目前尚無公開數據。但對于依賴持續集成/持續部署管道的團隊來說，哪怕短暫的窗口也足以讓惡意代碼進入構建環境。

GitHub令牌的特殊處理也值得注意。攻擊者沒有直接濫用，而是先驗證、再批量注入分支。這種"慢速+擴散"模式，比立即轉售或利用更能逃避檢測——直到某個被污染的分支被合并，或者被注入的載荷在下游觸發。

硬編碼Claude Code身份是一個有趣的信號。它暗示攻擊者對AI開發工具鏈的熟悉，也可能是一種針對特定受眾的心理戰術——看到熟悉的工具名，警覺性自然降低。

目前維護方尚未公布賬戶被入侵的具體方式。是釣魚、憑證泄露、還是供應鏈上游的進一步污染，這些細節將決定后續防御措施的針對性。但無論如何，一個31,000+星項目的發布管道被攻破，本身就是對開源治理結構的拷問。

對于每天pip install的開發者來說，這次事件提供了一個殘酷的提醒：星標數量不等于安全審計深度，版本號的小幅跳動可能藏著完整的攻擊鏈，而你最信任的基礎設施，可能正在你最不經意的導入語句中執行11MB的混淆代碼。