对很多从 GitHub 上自建代码库的团队来说，Gitea 是那个"开源又轻量"的家底。它管理着整个组织最值钱的东西：源码。也正因为自托管，它往往暴露在公网，被管理员当成果然要打补丁、却又总是排在"不着急"队列里的组件。2026 年 8 月 25 日，CISA 把 Gitea 的一个 CVSS 9.8 严重漏洞塞进了已知被利用漏洞（KEV）目录——这意味着一套不需要太多前提就能攻破自托管 Git 平台的代码注入通道，已经被真实攻击者用在了野。CVE-2026-60004 把"能写仓库的攻击者"直接升级成"能在服务器上执行命令的人"。
一、根因：diffpatch API 成了植入口
CVE-2026-60004 落在 Gitea 的 diffpatch 接口上，漏洞类型被归为代码注入（CWE-94）。这套接口的本职是处理补丁（patch）和应用到代码库的差异，但问题在于处理流程里埋了一个可以被利用的"检查点"：攻击者可以上传经过精心构造的恶意补丁，借助 Gitea 自身的处理逻辑，往仓库里植入可执行的 Git Hook。Git Hook 是 Git 本身就支持的一个机制——在提交、合并、推送等特定事件发生时执行一段脚本。它本是开发流程自动化（比如提交后跑测试、检查代码风格）的合法工具，但一旦攻击者能在仓库里写入自己的 Hook 脚本，就等于在服务端拥有了一个能随事件触发的执行入口。研究者的描述直白得多：这最终会以 "远程代码执行" 收尾，所有命令都在 Gitea 服务账户的上下文里运行——也就是能读写这台服务器上源码、配置和可能被 Gitea 引用到的周边资源。
二、为什么危险：源码服务器天然是提权的富矿
单独看，这似乎只是"拥有仓库写权限的人能执行代码"，但把它放回自托管 Git 平台的语境里就很值得警惕。Gitea 服务账户通常对仓库文件、配置、乃至与它集成在一起的 Webhook、凭据或部署密钥有访问能力。一个能在这类账户下执行命令的攻击者，实际摸到的不只是某一个仓库，而是整台服务器上 Gitea 触手可及的一切。加上平台默认支持用户注册和公开发布，只要攻击者能注册一个账号并接触到公开仓库，配合 gh 这类接口存在的隐患，就多了一条从"外部陌生人"一路走到"服务器命令执行"的路径——这正是它拿到 9.8 高分的原因：网络可达、低复杂度、无需特殊权限上下文、影响面直接越出仓库边界。
三、在野利用与处置
被列入 KEV 意味着 CISA 给出了明确的修复窗口（该条目要求相关方在数日内完成整改），也印证了这类漏洞的吸引力：面向公网、价值集中于一处、利用条件低。对运维自托管 Gitea 的团队来说，处置并不复杂但需要及时：
- 升级到修复版本（Gitea 1.27.1 及以后），这是根治手段；
- 在无法立即升级时，收紧暴露面：关闭不受信任的公开注册，限制谁能创建或写仓库；
- 对历史仓库做一次 Hook 与配置审计，排查是否存在非预期的 Git Hook、被篡改的部署密钥或异常推送；
- 关注 Gitea 服务账户所能触达资源的凭证情况，评估是否需要轮换被其引用的令牌与密钥。
CVE-2026-60004 的真正教训，不在于某一行代码写错了，而在于自托管基础设施的维护节奏往往跟不上它暴露给攻击者的价值。源码托管平台这类"一失守就全盘皆输"的组件，应当和 VPN、门户一样享有最高打补丁优先级——因为一次在 Git Hook 里的恶意写入，可能就意味着整个代码库的故事结束了。
参考：CISA 已知被利用漏洞目录、NVD 对 CVE-2026-60004 的公告、Gitea 1.27.1 发布说明。