Gitea 容器镜像仓库未授权暴露 —— 被搁置四年的"私有"幻象

CVE-2026-27771，30,000 个自托管实例的私有容器镜像在无需认证的情况下被泄露

摘要 (TL;DR)

2026 年 5 月 27 日，安全研究人员（英国 Noscope）披露了开源自托管版本控制平台 Gitea中的一个漏洞，该漏洞允许未经认证的远程攻击者在没有账户、密码或事先访问权限的情况下拉取私有容器镜像。该漏洞编号为 CVE-2026-27771，影响修复该问题的1.26.2 之前的所有版本。

据 Noscope 称，该缺陷可能影响 30 多个国家的 30,000 多个部署，且在近四年间未被发现。暴露主要集中于中国、美国、德国、法国与英国，受影响组织涵盖医疗机构、航空航天制造商、零售基础设施与互联网服务提供商（ISP）。

问题的本质很明确：运营者标记为"private（私有）"的容器仓库实际上并未提供该保护。互联网上的任何人都能在无账户、无密码、无事先访问权限的情况下，将私有容器镜像当作公开镜像一样拉取。这并非简单的 bug，而是对访问控制模型本身信任的崩塌。

关键判断 (Key Judgments)

#	判断	置信度
KJ-1	本缺陷的核心风险不是 RCE，而是机密泄露。容器镜像中常含有 API 密钥、数据库凭据与内部源代码，因此单个镜像的泄露即成为后续入侵的跳板。	High
KJ-2	鉴于约四年未被发现，部分实例的镜像可能已被悄然采集的可能性无法排除。补丁只能防止未来的暴露，无法收回过去的泄露。暴露的机密须视为已被攻陷。	Medium-High
KJ-3	Gitea 分支（尤其是已确认受影响的 Forgejo）在独立验证前应视为受影响。自托管 Git 平台因"我自己掌控，所以安全"的认知而易于延迟打补丁。	High
KJ-4	自托管 Gitea 是个人开发者、小型团队与区块链初创企业为节省成本而青睐的配置，因此损害可能集中于资产较少但安全运营能力较弱的组织。	Medium

2. 漏洞概述

CVE-2026-27771 是 Gitea 容器镜像仓库中的一个认证绕过缺陷。正常情况下，标记为私有的仓库应仅可由经认证的授权持有者拉取。然而在受影响版本中，私有标记未能提供运营者合理预期的保护。

据 Noscope 说明，Gitea 的容器镜像仓库允许互联网上的任何人——在无账户、无密码、无事先访问权限的情况下——从受影响实例拉取表面上看似私有的容器镜像，仿佛它们是公开的。

目前尚无更多技术细节公开（在负责任披露流程中属常见），CVSS 评分亦尚未评定（N/A）。然而，未经认证、远程、无需事先权限的条件表明其实际风险较高。

3. 影响范围与分支生态

项目	内容
受影响版本	1.26.2 之前的所有 Gitea 版本
修复版本	Gitea 1.26.2
估计暴露规模	30 多个国家、30,000 多个部署
暴露集中国家	中国、美国、德国、法国、英国
受影响行业	医疗、航空航天制造、零售基础设施、ISP
未被发现时长	约 4 年
分支影响	所有 Gitea 分支在验证前应视为潜在受影响。Forgejo 已确认受影响。

Noscope 强调，所有 Gitea 分支在各自维护者独立验证之前都应视为潜在受影响。在其自身测试中，Forgejo 被确认受影响。这再次暴露了分支生态的结构性弱点——上游缺陷无声地传播至众多下游项目。

4. 对韩国的影响

该漏洞在韩国媒体中几乎未获报道，但对国内自托管环境有直接影响。

第一，许多国内初创企业与区块链团队为节省 GitHub Enterprise 成本而自托管 Gitea/Forgejo。它们常在 OCI、AWS 或自有服务器上部署 Gitea 并使用容器镜像仓库功能。出于"内网或我掌控的服务器"的认知，不少团队将容器镜像仓库暴露于互联网运行。

第二，国内组织的延迟打补丁文化加剧了风险。自托管工具往往"装了就忘"，因此一个四年未被发现的缺陷在国内也很可能被长期搁置。

第三，容器镜像通常含有 .env 文件、API 密钥、数据库连接信息与内部源代码。若国内金融科技／区块链企业的镜像被泄露，这将直接等同于生产基础设施凭据的泄露。

5. 对 Web3 / 加密生态的影响

对 Web3 组织而言，该漏洞可能比一般企业更为致命。

第一，区块链项目的容器镜像中频繁含有节点运行密钥、RPC 端点凭据与部署脚本。镜像泄露即等同于基础设施密钥泄露，直接威胁主网节点、索引器与预言机运行。

第二，许多 DeFi/NFT 初创企业为节省 GitHub 成本而使用自托管 Gitea。据本分析师在大量 Web3 咨询过程中的观察，将智能合约部署私钥或多签运营脚本作为环境变量硬编码于容器镜像内部的案例并不罕见。

第三，当与本分析师 CTI-2026-0527-GLASSWORM 报告所指出的开发者凭据窃取流程相结合时，风险被放大。若 GlassWorm 类恶意软件窃取开发者令牌，而 Gitea 暴露又泄露了容器镜像内的额外机密，攻击者便可轻易掌控整个部署流水线。

6. 应对方案

6.1 即时措施

立即升级至 Gitea 1.26.2。这是根本性解决方案。
若无法立即打补丁，在配置中应用临时缓解措施 [service].REQUIRE_SIGNIN_VIEW=true。注意：在某些容器有意公开的环境中，此方法可能并不适用。
对 Forgejo 等分支，查看维护者的补丁公告；若未确认，则视为受影响并应用相同的缓解措施。

6.2 假设被入侵的事后应对

将暴露容器镜像中的所有机密视为已被攻陷并予以轮换——API 密钥、数据库凭据、RPC 凭据、部署密钥，全部。
分析访问日志——回溯检查容器镜像仓库拉取日志中来自未认证／外部 IP 的异常访问痕迹。（但四年的日志被保留下来的可能性较低。）
镜像卫生审查——今后从所有容器镜像中移除硬编码机密，并转向构建时机密注入（如 BuildKit secret mount）。

6.3 结构性措施

不将自托管 Git 平台直接暴露于互联网。将其置于 VPN、反向代理认证或 IP 白名单之后。
绝不在容器镜像仓库中包含机密。机密应通过 Vault、KMS 等专用机密管理器在运行时注入。
将自托管工具正式纳入补丁管理对象。终结"装了就忘"，至少每季度检查一次版本与 CVE。

7. 结论与建议

CVE-2026-27771 的教训是："private 标签并不等于安全。" 访问控制必须由实际的验证逻辑强制执行，而非标签；自托管环境因"我掌控"的心理安全感，反而更易在审查中被遗漏。

核心建议如下：

立即升级至 Gitea 1.26.2，或应用 REQUIRE_SIGNIN_VIEW 缓解措施。
不将容器镜像用作机密存储。假定放入镜像的所有凭据都可能已公开。
将自托管基础设施正式化为补丁／暴露管理对象。
Web3 组织应将节点密钥与部署密钥从镜像中完全分离，并迁移至外部机密管理器。

参考文献 (References)

[1] Ravie Lakshmanan, "Gitea Vulnerability Exposes Private Container Images without Authentication", The Hacker News, 2026-05-27. https://thehackernews.com/2026/05/gitea-vulnerability-exposes-private.html

[2] Noscope, "Gitea Instances Exposing Private Container Images". https://www.noscope.com/blog/gitea-instances-exposing-private-container

[3] Gitea, "Release of 1.26.2". https://blog.gitea.com/release-of-1.26.2/

[4] Dennis Kim, "GlassWorm C2 基础设施同步封锁", CTI-2026-0527-GLASSWORM, 2026-05-27. https://github.com/gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT