自託管的 Git 服務 Gogs 被發現一個 CVSS 9.4 分的嚴重參數注入漏洞,任何已驗證的用戶都能透過惡意分支名稱,將 exec 參數注入 git rebase 指令,進而遠端執行任意程式碼。 此漏洞是 Gogs 長期安全危機的最新案例,其唯一維護者多年來對多個嚴重安全報告不修補、不回應,引發各界呼籲用戶應儘速遷移。

Create a landscape editorial hero image for this Studio Global article: What critical unpatched remote code execution vulnerability was disclosed in the open-source Git service Gogs, what are its technical detail. Article summary: Here is a comprehensive answer covering the vulnerability, its technical details, the broader pattern of delayed response, and recommended actions.. Topic tags: general, general web, government. Reference image context from search candidates: Reference image 1: visual subject "How a Gogs Path Traversal Vulnerability Enables Remote Code Execution (CVE‑2025‑8110). Gogs Path Traversal and Remote Code Execution is a critical vulnerability affecting the self-" source context "Is Your Git Service Safe? How a Gogs Path Traversal Vulnerability Enables Remote Code Execution (CVE‑2025‑8110) | Ridge " Reference image 2: visual subject "How a Gogs Path Traversal Vulnerabil
近期,在開源、自託管的 Git 服務 Gogs 中揭露的嚴重安全漏洞,再次為該平台的使用者敲響了警鐘。這個漏洞的 CVSSv4 風險評分高達 9.4 分,屬於「嚴重」等級。它允許任何擁有一個基本使用者帳號的攻擊者,在主機伺服器上執行任意命令。然而,比漏洞本身更令人不安的,是它的修補狀態:儘管早在 2026 年 3 月就已通報給專案的維護者,但至今仍無官方修復程式釋出 。對於全球數以千計自託管 Gogs 實例的管理員來說,理解這個漏洞的運作機制,並立即採取應變措施,是當前刻不容緩的任務。
這個漏洞屬於典型的參數注入弱點(CWE-88),問題核心出在 Gogs 處理拉取請求(Pull Request)的方式。當程式庫(Repository)的合併方式設定為「Rebase before merging」(變基後合併)時,使用者所建立的拉取請求中,其來源分支(Source Branch)的名稱會被直接傳遞給伺服器上執行的 git rebase。
關鍵的失誤在於,Gogs 的程式碼在調用命令列工具時,遺漏了一個標準的安全做法:沒有使用 -- 分隔符號來明確標示「選項的終點」。這意味著,如果攻擊者將自己的分支命名得像是
--exec='惡意指令',系統就不會將其視為一個分支標籤,而是將它理解為 git rebase--exec 參數的原意是讓 Git 在重播每個提交時,執行一個指定的 Shell 命令。最終的結果,就是讓攻擊者能夠以 Gogs 伺服器程式的權限,在底層作業系統上執行任意程式碼 。
攻擊流程一覽:
--exec 參數,後面緊接其想要執行的 Shell 命令 發現此漏洞的 Rapid7 Labs 安全研究員 Jonah Burgess 一語道破了其中的機制:「該漏洞允許任何已驗證的使用者,透過建立一個帶有惡意分支名稱的拉取請求,將 --exec 參數注入 git rebase
對於長期關注 Gogs 專案的人來說,這個嚴重的未修補零時差漏洞並不令人意外。這只是該專案多年來的一種模式──眾多安全報告都遭到專案唯一(實質上)維護者的沉默以對──當中最新的,也是最嚴重的一個案例。
多個獨立的資安研究團隊記錄了這段被忽視的歷史:
這一系列的歷史,讓 Rapid7 這次的揭露,其意義已遠超一份單純的安全公告。正如一家業界媒體所言,此情此景「提醒了我們開源專案的侷限性」,尤其是當其依賴一位不回應的單一維護者時 。缺乏有效的多方治理,一項被廣泛使用的關鍵基礎設施,就可能成為一個永久性的風險。
由於沒有軟體修補程式可用,管理員必須仰賴調整組態和網路層級的控管,來化解這個攻擊途徑。以下步驟可以阻止眼前的威脅並縮小受攻擊面。
1. 立即停用「Rebase before merging」
這是唯一最有效的緩解措施。整個攻擊鏈完全依賴這個特定的合併模式。將程式庫或全站設定改為「Merge commit」(合併提交)或「Squash」(壓縮合併),就能徹底消除這段存在漏洞的程式碼路徑 。
2. 限制網路存取來源
要發動此攻擊,需要透過 HTTP 進行驗證並建立拉取請求。如果您的 Gogs 伺服器不需要公開,請將其置於 VPN 或防火牆後方,只允許信任的內部使用者連線。這樣做可以讓平台遠離大規模的網路掃描和隨機攻擊者。
3. 緊縮使用者註冊與權限
既然任何已驗證使用者都能利用此漏洞,那麼,儘可能減少伺服器上的帳號數量就是一項關鍵防禦。請停用自行註冊功能,改為手動審核新使用者。同時,立即稽核您的使用者清單,並停用任何已失效或來路不明的帳號 。
4. 監控可疑的拉取請求
請對拉取請求的分支名稱進行嚴密監控,留意當中含有可疑字元的名稱,包括雙破折號(--)、分號、反引號、或明顯的 Shell 命令關鍵字,例如 exec、curl、wget 等。不尋常的分支名稱是有人正在嘗試利用此漏洞的強烈跡象 。
5. 規劃您的長期「脫離 Gogs」方案
鑑於其重大漏洞長期未修補的歷史紀錄,繼續依賴 Gogs 已是一種策略性的風險。目前最可行的替代方案是 Gitea,它是由社群主導的 Gogs 分支,擁有一個健全、由多位維護者組成的開發團隊,以及反應迅速的安全程序。市場上當然還有其他主要的 Git 服務平台,但對於當初看上 Gogs 輕量、可自託管特性的團隊來說,Gitea 幾乎是一個可直接替換的選擇,能徹底解決單一維護者瓶頸的問題 。
6. 為可能到來的修補程式做好準備
請持續關注 Gogs 的安全頁面和 GitHub 上的版本發布。如果最終有修補程式釋出,請立即升級。但同時,也請以「這樣的模式將會重演,未來某個重大漏洞又將在未修補的狀態下拖延數月」為前提,來規劃您的安全防護策略。
Studio Global AI
Use this topic as a starting point for a fresh source-backed answer, then compare citations before you share it.
自託管的 Git 服務 Gogs 被發現一個 CVSS 9.4 分的嚴重參數注入漏洞,任何已驗證的用戶都能透過惡意分支名稱,將 exec 參數注入 git rebase 指令,進而遠端執行任意程式碼。
自託管的 Git 服務 Gogs 被發現一個 CVSS 9.4 分的嚴重參數注入漏洞,任何已驗證的用戶都能透過惡意分支名稱,將 exec 參數注入 git rebase 指令,進而遠端執行任意程式碼。 此漏洞是 Gogs 長期安全危機的最新案例,其唯一維護者多年來對多個嚴重安全報告不修補、不回應,引發各界呼籲用戶應儘速遷移。
當前的緊急應變方案是立即停用「Rebase before merging」合併選項,並將伺服器限制在信任網路內;長遠之計則需考慮遷移至維護更活躍的 Gitea 等分支。