Gitea 是一個廣泛使用的自託管 Git 平台，近期披露了一個評分高達 9.8 分的嚴重漏洞 CVE-2026-59774。這個漏洞允許未經身份驗證的攻擊者，在不需要登入且不需要對儲存庫有寫入權限的情況下，直接讀取伺服器上 Gitea 服務帳號可訪問的任何檔案。
漏洞成因與技術脈絡
這次漏洞的核心在於 Gitea 如何處理 Org-mode 標記語言的渲染。Org-mode 是一種用於筆記、計畫與文件撰寫的格式，Gitea 為了支援這種格式的支援，使用了名為 go-org 的第三方庫來將 Org-mode 內容轉換為可視化的網頁內容。
在受影響的版本（1.22.1 至 1.27.0）中，Gitea 在初始化 go-org 時，直接使用了該庫的預設設定，而沒有覆蓋 ReadFile 這個回呼函數。ReadFile 函數的作用是定義當程式需要讀取外部檔案時應該如何操作。在 go-org 1.9.1 版本中，這個函數預設直接調用 ioutil.ReadFile，也就是直接從伺服器的檔案系統讀取路徑。
Org-mode 語法中有一項指令叫做 #+INCLUDE，它允許使用者將另一個檔案的內容包含進來。由於 Gitea 沒有對這個讀取行為進行路徑限制或權限檢查，攻擊者只要在 Org-mode 內容中寫入絕對路徑（例如 /etc/passwd），伺服器就會乖乖地將該檔案內容讀出並渲染在網頁上。
攻擊路徑與觸發條件
攻擊者不需要登入帳號，只需要利用 Gitea 的 markup 渲染端點（POST //markup）即可發動攻擊。
觸發此漏洞的唯一前提是：該 Gitea 實例中必須存在至少一個公開的儲存庫（Public Repository）。因為 Gitea 在處理該請求時會檢查讀取權限，對於公開儲存庫，匿名請求會通過權限檢查。如果一個 Gitea 實例將所有儲存庫都設為私有，則無法透過此路徑進行匿名攻擊。
從檔案讀取到遠端程式碼執行（RCE）的升級路徑
雖然這個漏洞表面上是檔案讀取（Arbitrary File Read），但它可能演變成極其危險的遠端程式碼執行（RCE）。
攻擊者可以嘗試讀取 Gitea 的設定檔 app.ini，從中獲取 INTERNAL_TOKEN（內部認證令牌）。拿到這個令牌後，攻擊者可以利用 Gitea 的內部日誌系統注入惡意的 Git Hook（Git 鉤子，即在特定事件觸發時自動執行的腳本）。最後，當攻擊者觸發一次匿名複製（Anonymous Clone）操作時，該惡意鉤子就會被執行，從而讓攻擊者完全控制伺服器。
修復方案與實務建議
Gitea 已在 1.27.1 版本中修復此漏洞。修復方式是覆蓋了 ReadFile 回呼函數，確保 Org-mode 的包含路徑僅被視為純文字內容渲染，而不會被解析為伺服器檔案系統的實際路徑。
對於維運工程師的建議：
第一，立即升級。請將所有自託管的 Gitea 實例更新至 1.27.1 或更高版本。
第二，檢查日誌。檢查是否有異常的 POST 請求指向 //markup，特別是內容包含絕對路徑或指定使用 Org-mode 渲染的請求。
第三，假設已遭入侵的處置。如果發現有可疑的觸發紀錄，僅僅升級是不夠的。因為攻擊者可能已經讀取了敏感資訊。建議採取以下輪換（Rotate）措施： 更換 INTERNAL_TOKEN。 更換 OAuth 相關金鑰。 更換 JWT 簽名金鑰。 更換資料庫連線密碼。
第四，檢查鉤子目錄。檢查儲存庫的 hooks 目錄中是否出現了非預期的可執行檔案。
來源：thehackernews.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。