GhostAction再襲GitHub：刪除金鑰後，Git 歷史仍可能成為缺口

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-13

GitHub供應鏈攻擊GhostAction近日再被揭發。iThome報道指出，攻擊者利用兩個遭入侵的維護者帳戶，向346個儲存庫加入偽裝成安全檢查的惡意自動化工作流程；當中279個屬從其他專案複製而來的儲存庫。受影響項目包括開源遊戲引擎Pyxel，以及Uber旗下AthenaDriver。對依賴GitHub Actions作測試、建置或發布的團隊而言，風險不只在於某個程式碼庫被改動，更在於CI/CD流程可接觸到的憑證可能已被帶走。

現階段亦有重要限制。iThome引述StepSecurity的檢查結果稱，AthenaDriver的惡意工作流程曾把資料傳送至攻擊伺服器並取得回應，但調查人員仍未能確認實際有多少有效憑證外洩。OpenSourceMalware截至10月9日所追查到的790個公開儲存庫，則是曾經遭植入惡意流程的累計調查數字，不能直接等同於10月8日事件中的346個儲存庫，也不代表每個項目均有可被濫用的金鑰。受影響範圍及攻擊歸因仍可能隨調查更新。

攻擊焦點由目前程式碼延伸至歷史提交

iThome指出，GhostAction最早在2025年9月曝光，其手法是先取得GitHub帳戶的寫入權限，再在該帳戶可修改的儲存庫中放入惡意工作流程。正常的GitHub Actions會在指定事件下自動執行測試、建置或發布工作；一旦惡意檔案獲執行，便可讀取流程可存取的套件發布憑證、雲端服務金鑰等機密，再傳送到攻擊者的伺服器。換言之，攻擊者不一定要先入侵每個專案的應用程式環境，維護者權限及自動化流程本身已可成為切入點。

這次被揭露的版本，令事件的風險邊界更大：惡意工作流程會取得儲存庫可存取的完整Git提交歷史，掃描舊有程式碼變更，以尋找AWS、GitHub及OpenAI等服務的金鑰或存取權杖。iThome又指出，流程會擷取部分AWS金鑰附近的程式碼，嘗試識別其他相關機密。即使開發者已在目前分支刪除敏感字串，只要它曾被提交並仍存在於歷史紀錄，仍可能被翻出。

這令「已修正」需要分成兩個層面理解。從程式碼品質角度看，刪除明文金鑰可避免它繼續出現在最新版本；但從憑證安全角度看，舊提交所留下的值一旦曾被外部讀取，便不能假設它仍然安全。這是Git歷史帶來的實際營運問題：團隊若只檢視當前檔案，可能低估了自動化流程可接觸到的資料範圍。

為何單純刪除惡意檔案不足夠

iThome報道中，AthenaDriver的案例反映另一個容易被忽略的權限問題：原開發者仍保有寫入權限，令攻擊者可直接在主要分支加入惡意工作流程。對專案管理者來說，儲存庫擁有者、舊維護者、外部貢獻者及自動化帳戶的權限，不能只在新成員加入時處理。當帳戶狀態、職責或合作關係改變，持續有效的寫入權限也可能把原本局限於一個帳戶的事故，擴大至多個可修改的專案。

更關鍵的是，刪除工作流程只會阻止已知檔案再次執行，並不會令已傳送出去的憑證自動失效。iThome指出，調查團隊建議受影響專案移除惡意流程、撤銷遭濫用的GitHub存取憑證、檢查歷史紀錄並更換可能外洩的金鑰，同時清查攻擊期間發布的套件和已部署的系統。這個次序背後的含意很直接：若有效金鑰已落入攻擊者手中，後續風險可發生在原始儲存庫以外。

以AWS金鑰為例，團隊需要處理的未必只是儲存庫內容，還包括相連的雲端資源存取；套件發布憑證則可能牽涉攻擊期間是否出現非預期版本。至於GitHub與OpenAI等服務的存取權杖，應按各自可觸及的資源及用途評估。這些並非已確認的個別濫用結果，而是由iThome所述的憑證搜尋範圍所引出的合理應變方向；在外洩有效憑證數量未明之前，保守輪換通常比等待完整取證更能縮短暴露時間。

團隊應把調查拆成憑證、流程與發布三條線

首先是帳戶與憑證。曾擁有受影響儲存庫寫入權限的維護者，應優先檢查其GitHub存取憑證是否可能遭濫用，並撤銷可疑或不再需要的權杖。對曾經出現在Git歷史、工作流程設定或相關程式碼片段的AWS、GitHub及OpenAI金鑰，較合適的處理方式是重新簽發及替換，而非只從檔案移走文字。輪換後亦應確認部署設定、建置流程及依賴它們的服務已使用新憑證，否則修復容易卡在中途。

其次是工作流程本身。團隊需要檢閱儲存庫內新增、修改或名稱看似安全檢查的Actions設定，尤其關注攻擊調查所涵蓋期間的改動，以及主要分支是否有非預期提交。iThome描述的攻擊利用自動化工作流程讀取可取得的資料，故審核時不宜只問「程式碼有沒有惡意內容」，還要問「此流程在執行時可讀到哪些憑證和資料」。這有助釐清哪類機密須先輪換，以及哪些項目需要更深入追查。

第三條線是發布與部署紀錄。iThome所引建議特別提到，應清查攻擊期間發布的套件及部署的系統。對開源維護者而言，這代表需要回看是否有不尋常的發布活動；對企業開發團隊而言，則應對照自動化部署、雲端存取及憑證使用紀錄。目的不是預設已有後續入侵，而是把「工作流程曾向外傳送資料」與實際環境的變更紀錄連結起來，縮窄需要處置的範圍。

香港團隊的風險在於共用的開發模式

iThome報道未提及香港有直接受害機構，亦沒有提供本地影響資料；不過，香港開發團隊、開源維護者及使用雲端CI/CD的開發者，若採用同類GitHub協作和自動化發布模式，面對的是相同的結構性風險。尤其是多個專案由少量維護者管理、歷史上曾把金鑰寫進程式碼、或保留舊合作夥伴寫入權限的情況，事故一旦發生，排查工作往往跨越多個儲存庫和多種雲端服務。

從管理角度分析，GhostAction提醒團隊把「秘密是否已從目前程式碼刪除」改為「這個秘密曾否在任何可被流程讀取的歷史、設定或帳戶範圍出現」。前者是單一檔案的問題，後者涉及版本紀錄、身分權限和發布鏈路。這個轉變會增加審核及輪換成本，但可避免把修復錯誤地停在刪除一個YAML檔案的階段，這一步對資源有限的團隊尤其重要。

接下來值得觀察的是調查人員能否確認更多有效憑證外洩或後續套件、部署遭濫用的證據，以及790個公開儲存庫的累計數字會否繼續上升。在此之前，曾接觸受影響專案的維護者和依賴其發布成果的團隊，應優先完成權限覆核、工作流程審計及金鑰輪換，並保留足夠紀錄以便日後釐清影響範圍。