Forgejo 修复模板仓库远程执行漏洞，清理一次不是信任边界
据 Forgejo 16.0.4 官方发布说明，该版本修复了一项标记为 Critical 的问题：恶意模板仓库可利用模板展开过程干扰 Git 仓库初始化，进而读取宿主数据或执行进程。16.0.4 于 9 月 10 日发布。
作者：韩启明｜OC 政策与安全编辑
据 Forgejo 16.0.4 官方发布说明，该版本修复了一项标记为 Critical 的问题：恶意模板仓库可利用模板展开过程干扰 Git 仓库初始化，进而读取宿主数据或执行进程。16.0.4 于 9 月 10 日发布。
一句话结论：风险发生在“处理不可信模板，再把结果交给 Git”的接缝处；文件经过一次清理，并不代表后续转换不会重新造出危险结构。
看起来只是复制模板，实际上经历了身份变化
代码托管服务提供模板功能，本来是为了让新项目不必从空目录开始。用户选择模板，平台复制内容、替换变量，再建立独立仓库。
问题在于，同一目录中的文件在不同阶段具有不同含义。普通文件可以只是项目内容；某些特殊目录或配置一旦被 Git 识别，就可能影响后续操作行为。
官方说明指出，先前流程删除原有 Git 元数据后进行模板展开，而展开结果可能重新产生相关结构。修复因此在展开完成后、初始化之前再次移除不应存在的目录。来源：修复说明
这里不需要把具体利用步骤交给读者，也能理解核心错误：安全检查覆盖的是转换前的对象，真正被执行工具接收的却是转换后的对象。
“我已经检查过输入”为什么仍然不够
这类问题不只出现在代码仓库。压缩包解压、模板渲染、文件名替换和配置合并，都可能改变数据的结构与含义。
假设一个系统在上传时禁止特殊路径，却在后续变量替换中产生了新的路径，那么上传检查并没有覆盖最终状态。检查不是盖章，不能从一个阶段自动继承到另一个阶段。
更可靠的思路，是在跨越信任边界时验证实际交付物：路径是否仍在允许范围内？特殊文件是否被重新生成？工具会不会把本应作为数据的内容解释成配置或指令？
这个顺序尤其值得使用 Agent 自动处理仓库的团队注意。模型可以负责改文件，但执行环境必须负责约束文件最终能影响什么。不能把“模型没打算攻击”当作输入可信的依据。
受影响实例应优先做什么
对于运行 16.x 的管理员，应优先核对自己实际运行的版本，并按照官方说明升级到已修复版本。其他维护分支需要查看各自的安全发布，不能把 16.0.4 当作所有分支唯一的升级路径。
版本确认也应覆盖真正对外服务的进程。下载了新二进制、修改了镜像标签，不等于所有实例都已经重启到新版本；多副本部署尤其需要逐个确认。
如果怀疑实例曾遭到利用，应保存日志、仓库创建记录和相关系统证据，再按事件响应流程调查。完成补丁安装不能证明此前没有数据读取或进程执行，补漏洞与查入侵是两项工作。
这里没有证据表明所有公开实例都已被攻击，也不应凭漏洞严重级别直接估算受害规模。
另一个修复提醒：用户能做，不等于令牌也能做
本次说明还列出 API 权限检查的修正，涉及维护者编辑拉取请求时，没有充分应用访问令牌自身的限制。
这体现了另一种容易混淆的边界：用户身份拥有的权限，可能大于某个令牌被授予的权限。使用受限令牌时，应以授权范围的交集为准，而不是因为用户有资格就放行全部操作。
对于自动化工具，这是特别实际的问题。团队常为 Agent 创建仓库限定令牌，正是为了让它不能横向影响其他项目。如果某条特殊业务路径绕过了令牌限制，表面上的最小权限就会失效。
功能越便利，越要查清它调用了谁
模板功能不是孤立的文本处理器，它最终会调用版本控制工具并接触宿主资源。安全审查不能只看 Web 接口是否校验了参数，还要追踪后续工具如何理解文件。
这也是开源托管平台值得投入维护资源的原因。代码仓库不仅存储源码，还可能连着发布凭据、自动构建和内部协作系统。一个看似边缘的便利功能，可能位于整条供应链的入口。
关键事实
- Forgejo 16.0.4 于 2026 年 9 月 10 日发布。
- 官方将模板仓库相关远程执行问题标记为 Critical。
- 修复重点包括模板展开后的清理，以及 API 令牌权限检查。
- 漏洞存在与某个实例已被入侵是不同结论，需要分别核查。
OC 判断
值得记住的不是“再删一次目录”这个补丁动作，而是更一般的原则：不可信数据经过转换后，必须重新验证其实际含义。安全边界应跟着数据的用途走，而不是停留在最初的入口。
为什么重要
- 对管理员：优先修复，并确认运行版本而非下载版本。
- 对开发者：检查最终交给底层工具的对象。
- 对企业：代码平台补丁管理应纳入供应链风险治理。
评论
围绕这篇文章补充信息、提出问题或分享观察。