Gitea CVE-2026-27771：四年來，「私有」容器映像其實沒有私有——30,000 個自架實例正在大開門

2026 年 5 月 27 日，Noscope 資安研究員揭露 CVE-2026-27771——Gitea 容器登錄表（container registry）的一個關鍵身分驗證繞過漏洞，未經身分驗證的遠端攻擊者，可以在沒有帳號、沒有密碼、沒有 token 的情況下，把任何「私有」容器映像拉下來。所有 2022 年以後到 1.26.2（不含）以前的 Gitea 版本通通中標。Noscope 估計全球超過 30 國有 3 萬個以上的對外可達 Gitea 部署，集中在中國、美國、德國、法國、英國，跨越醫療、航太、零售基礎設施、ISP。如果你自架 Gitea、又曾經把 OCI 映像 push 上去——你的程式碼、你的祕密、你的 base layer——就請假設「別人已經拉走了」。

一、白話說，到底壞了什麼

Gitea 的容器登錄表對外開放標準的 OCI registry API（Docker / Helm / OCI 的拉取協定）。當一個 repository 被標為「私有」時，UI 與上層 REST 介面都正確執行了這個權限檢查。但 registry 端點沒有。「私有」這個旗標只在 repository metadata 層被檢查，沒有在實際提供 blob／manifest 的那一層被檢查。任何人只要知道（或猜得到）manifest URL——而 URL 規則是公開、官方文件化的 OCI 慣例——就可以 docker pull 那張映像，像它是公開的一樣。

這是「同一個資源有多條存取路徑、其中一條漏掉授權檢查」的教科書級案例。也是 AI 輔助稽核非常擅長挖掘的這類 bug，這也部分解釋了為什麼我們同一個月看到 18 年的 NGINX 漏洞與 4 年的 Gitea 漏洞接連被揭露。

二、為什麼這個比一般 CVE 更糟

三個放大器。

外洩是無聲的。攻擊者只要對公開的 OCI 端點下標準 docker pull，不會留下明顯痕跡。你的 access log 會看到一個任意 IP 的影像抓取請求。如果沒有 registry 層級的稽核日誌——多數自架 Gitea 維運者並沒有開——你事後沒辦法知道誰拉了什麼。

容器映像通常裝著祕密。多數開發團隊或多或少，曾經在本地開發階段把 API key、資料庫 URL、.env、service account JSON 一起包進映像，然後 push 上去「反正是我的私有 registry」。「私有」這個假設現在被回溯地證實為假。

窗口已經開了四年。一個從 2022 年起就靜靜可被利用的漏洞，統計上，已經被靜靜利用過。沒有什麼「我們應該沒事」的誠實版本。對的問題是：「我們在什麼時候 push 了什麼？那些 layer 裡到底有什麼？」

三、30 分鐘事故反應 runbook

第 0 到 5 分鐘：打補丁或關門。升級到 Gitea 1.26.2（或更高）。如果現在沒辦法升級，就在 app.ini 設 [service].REQUIRE_SIGNIN_VIEW=true 並重啟。這是暫時性緩解，會打壞所有真正公開的映像——未來 24 小時內，接受這個取捨。

第 5 到 15 分鐘：盤點。跑 gitea admin packages list-by-type container（或對 package 與 package_version 的等價 SQL），列出所有 push 到私有 repo 的映像與 tag。把所有「在打補丁的版本部署前 push」的，標為「可能外洩」。

第 15 到 25 分鐘：輪替。對每一張「可能外洩」的映像，把所有曾出現在任何 layer 的祕密通通換掉。AWS key、GCP service account、資料庫密碼、Stripe key、OAuth client secret、JWT 簽章金鑰——全部。不要先去 grep 確認，假設它們在、直接輪替。事後再 grep 回查。

第 25 到 30 分鐘：通報。如果你的 Gitea 對外可達，寫一段話的事件摘要給資安關係人，以及（在被要求的情況下）你的主管機關。前面誠實的成本，遠遠低於三週後在追問下誠實的成本。

四、為什麼 2026 年自架族變成最高風險族群

今年的模式——laravel-lang 供應鏈、NGINX Rift、SharePoint 反序列化、現在再加 Gitea——很一致：被廣泛部署的自架基礎設施裡，關鍵 bug 出現的速度，已經超過一般系統管理員打補丁的速度。Managed SaaS 的對手通常在揭露後幾小時內就補完。自架族最快是幾天，常態是幾週，最差是幾個月。

自架的成本帳已經位移。2022 年，自架 Gitea 比 GitHub Enterprise 每位開發者每月省你 4 美金。2026 年，當你誠實把「一位全職工程師花在資安維護（追補丁、CVE 回應、稽核日誌、base image 衛生、憑證輪替）的合理比例」算進去，損益平衡點已經明顯向 managed 方向移動。

這不代表自架是錯的。它代表 2026 年自架的誠實預算，包含一個指定負責人與一筆真實的維護人力。如果你兩樣都沒有，你每一季都在累積一筆「Gitea CVE 形狀」的負債。

五、本來可以早點抓到這件事的防禦控制

三個控制，依部署成本由低到高：

網段隔離。自架的開發基礎設施（Gitea、內部 CI runner、容器登錄表）不應該掛在公開網路上，除非有可辯護的理由。放到 VPN 後面，或放到零信任閘道後面。那 3 萬個對外暴露的 Gitea，多數一開始就沒必要對外。

Registry 層級的稽核日誌。把每一次 pull 與 push forward 到 SIEM（Loki、Splunk、甚至每天 rollup 的一個 S3 bucket）。儲存的邊際成本微不足道；下次 CVE 落地時的鑑識價值是巨大的。

push 時的祕密掃描。trufflehog、gitleaks、與更新的 LLM 輔助掃描器（Snyk 的、GitHub Advanced Security、Anthropic 驅動的開源等價物），在 CI 跑成本幾乎是零，本來就能擋下現在正在外洩的大部分東西。

我的觀點

CVE-2026-27771 是今年第三個被廣泛部署的自架基礎設施漏洞，而面向維運的答案都是同一句：「你需要一個人專職盯這件事，而你沒有那個人。」這個角色現在有名字了：在開源圈是「生態系維護者」（看新成立的 PHP 基金會資安團隊），在企業內是「平台工程負責人」。如果你自架，又兩者都沒有，你 Q3 的 roadmap 應該包含把這個角色聘起來或外包出去——不是奢侈品，是基本衛生。「我們五年前架了一台 Gitea 就忘了它」的時代結束了。這個姿勢的帳單，現在每兩個禮拜就會寄一次。