謝至恩GitHub 近日揭露並修補一項重大遠端程式碼執行漏洞 CVE-2026-3854，影響 GitHub.com 、 GitHub Enterprise Cloud 、 GitHub Enterprise Cloud with Data Residency 、 GitHub Enterprise Cloud with Enterprise Managed Users，以及 GitHub Enterprise Server(GHES) 。這項漏洞由 Wiz 研究人員通報，攻擊者只要具備任一儲存庫的 push 權限，甚至是自行建立的儲存庫，就可能透過一次特製的 git push 操作，在處理推送作業的 GitHub 伺服器上執行任意指令。
這項漏洞的 CVSS 評分為 8.7，問題源自 GitHub 內部服務在處理 git push options 時，未充分過濾使用者可控制的輸入值。 GitHub 在推送流程中會於多個內部服務間傳遞中繼資料，而該內部格式使用分隔符號來區分欄位；當使用者輸入中也能帶入相同分隔符號時，攻擊者便可注入額外欄位，使下游服務將其誤判為可信任的內部設定。
本文目錄
漏洞可繞過沙箱並接管執行環境
GitHub 說明，研究人員透過串連多個注入值，示範攻擊者能改寫推送作業所使用的處理環境，進一步繞過原本限制 hook 執行的沙箱保護，最後在伺服器上執行任意指令。 The Hacker News 引述技術細節指出，攻擊鏈涉及注入非正式環境的 rails_env 值、改寫 custom_hooks_dir，以及利用 repo_pre_receive_hooks 搭配路徑穿越觸發任意指令執行。
Wiz 指出，這項漏洞在 GHES 環境中可能導致伺服器遭完整控制，進而存取所有儲存庫與內部機密。對 GitHub.com 而言，漏洞則可能讓攻擊者在共用儲存節點上執行程式碼，造成跨租戶資料暴露風險；Wiz 表示，受影響節點上可觸及數百萬個公開與私有儲存庫。
GitHub 兩小時內完成修補，未發現遭濫用跡象
GitHub 表示，Wiz 於 2026 年 3 月 4 日透過 Bug Bounty 計畫通報漏洞後，安全團隊在 40 分鐘內重現並確認問題嚴重性。 GitHub 工程團隊於同日確認根因，並在一個半小時後將修補程式部署至 GitHub.com，整體從通報到修補不到兩小時。
GitHub 後續也進行鑑識調查。由於攻擊會迫使伺服器進入 GitHub.com 正常作業不會使用的異常程式路徑，GitHub 得以透過遙測資料追蹤相關活動。調查結果顯示，所有觸發該路徑的紀錄都對應 Wiz 研究人員測試活動，沒有其他使用者或帳號觸發相同路徑，也沒有客戶資料因漏洞遭存取、修改或外洩。
企業版用戶應立即更新並檢查紀錄
GitHub.com 與 GitHub Enterprise Cloud 相關服務已於 3 月 4 日完成修補，使用者不需額外採取行動。 GHES 用戶則需升級至 3.14.25 、 3.15.20 、 3.16.16 、 3.17.13 、 3.18.7 、 3.19.4 、 3.20.0 或後續版本。 GitHub 也建議 GHES 管理者檢查/var/log/github-audit.log，留意 push options 中包含「;」的推送操作。
SecurityWeek 報導指出，GHES 修補程式已於 3 月 10 日釋出，但 Wiz 在公開揭露時表示，仍有 88% 的企業版執行個體尚未更新至修補版本。由於漏洞利用門檻僅需具備 push 權限，企業若將 GHES 作為內部程式碼與機密管理核心，延遲更新可能讓攻擊者在取得一般開發者帳號後，進一步擴大為平台層級的入侵。
內部協定也可能成為攻擊面
GitHub 也在修補輸入過濾問題之外，移除不應存在於特定執行環境中的程式路徑。 GitHub 指出，該程式路徑原本只應用於其他產品設定，但在部署模型變更後，舊有排除機制未被延續，導致攻擊鏈有機會利用不必要的程式碼。
這起事件凸顯，多服務架構中的內部協定並不必然安全。當不同語言、不同服務透過共同格式交換資料，只要使用者可控制的欄位與安全關鍵設定共用同一資料通道，就可能形成注入攻擊面。對企業開發與平台團隊而言，除了修補 GitHub Enterprise Server，也應重新檢視內部服務間的資料邊界、欄位信任模型與設定來源，避免類似問題在自有平台中重演。