2026 年 4 月 28 日，一名安全研究者在个人博客发文称，他因为 Fedora 从 Pagure 迁移到 Forgejo，开始审视 Forgejo 的安全状态。

他的说法很重：只用“下班后一晚”，就发现了 SSRF、认证机制疏漏、加密实践问题、信息泄露、DoS、TOCTOU 等多类问题。更严重的是，作者称其中一部分可以串成远程代码执行、密钥泄露、持久账户访问和 OAuth2 提权。

但这事不能写成“Forgejo 全部实例被远程接管”。原文提到，RCE 依赖两个前提：开放注册，以及一个被设为非默认值的配置项。作者称部分实例确实这样配置，但这不是所有部署的默认状态。

我更在意的是另一件事：Forgejo 正被放到关键开源基础设施的位置上，但外界对它安全基线的信任，可能已经跑在可验证证据前面。

研究者披露了什么：严重性证据，不是攻击手册

作者没有公开完整漏洞链，也没有给出可复现步骤。

他展示的是经删节的 PoC 输出、PoC 文件哈希，以及本地测试环境里命令执行成功的片段。输出里能看到一些高风险结果，比如创建后门管理员账户、通过 git push stderr 回传服务器端 hook 执行结果。

关键路径被遮住了。

这就是作者所说的 carrot disclosure：不直接公开完整攻击链，但放出足够严重的证据，逼项目方做审计和响应。

这类披露方式有现实张力。对研究者来说，直接公开细节会增加攻击风险；只私下报告，又可能被拖延。对项目方来说，缺少完整细节会提高定位成本。对管理员来说，最难受：知道风险很大，却不知道哪一刀会落到自己身上。

事项原文披露到什么程度不能外推成什么对管理员的含义
漏洞类型SSRF、认证问题、信息泄露、DoS、TOCTOU、加密实践问题等不能据此断言每个实例都有同一漏洞链按系统性风险处理，不只等单个 CVE
RCE 条件开放注册 + 一个非默认配置项不能写成默认安装即可 RCE先检查注册策略和非默认高风险配置
证明材料经删节 PoC 输出、文件哈希不能补写攻击步骤等公告时也要先降暴露面
影响对象公开 Forgejo 实例、依赖其托管代码的社区不能说 Fedora 已被攻破迁移、托管和权限策略都要重新评估

目前还看不清的是版本范围、官方确认状态和修复节奏。原文没有给出这些信息，就不能替项目方下结论。

但已经能看清一点：这不是一个“某个小功能出 bug”的叙事。它更像是在问 Forgejo 的代码安全基线和响应机制，是否能托住更大的公共信任。

Fedora 迁移把 Forgejo 推到了更亮的灯下

Fedora 从 Pagure 迁移到 Forgejo，是这次审视的触发因素。

这句话要小心读。它不等于 Fedora 基础设施已经被攻破。原文没有这样的证据。

它真正改变的是信任半径。Fedora 这类发行版社区做出迁移选择，会让更多人把 Forgejo 看作可承接大型开源社区的基础设施。攻击者也会用同样的眼光看它。

代码托管平台承载的东西，远不只是 Git 仓库。

它还可能包含维护者身份、访问令牌、OAuth 授权、webhook、服务端 hook、发布流程、CI/CD 触发链路。一个账户被持久控制，未必马上表现为“服务器被打穿”。它也可能先变成一次悄悄的 release 篡改、依赖替换，或者维护权限转移。

Forgejo 是 Gitea 的社区分支，Codeberg 等公共代码托管服务也走这一技术路线。它的价值正来自社区属性。但社区属性不能自动兑换成安全能力。

开源可审计，是条件，不是结论。门开着，不代表已经有人把每个房间都查过。

这里可以拿商业平台做一个现实对照。GitHub Enterprise、GitLab 这类平台通常有专职安全团队、漏洞赏金、企业客户压力和较固定的安全公告流程。社区项目也能做得很好，但它更依赖维护者时间、外部报告和公开压力。

这不是说 Forgejo 不该被采用。更准确的说法是：当它开始承接大型社区迁移，安全治理就不能再停留在“小项目靠信任运转”的状态。

对正在评估迁移的团队，最实际的选择不是立刻否定 Forgejo，而是延后高权限迁移，先等两类信息：维护方是否给出安全边界说明，主要公共实例是否同步收紧注册和高风险功能。

对已经使用 Forgejo 的团队，重点不是恐慌换平台。换平台本身也有成本，还可能引入新风险。更现实的动作，是把公开暴露面先压下来。

管理员现在该做什么：先降暴露面，再等定论

Forgejo 实例管理员不需要猜完整漏洞链。猜不到，也不该猜。

眼下更有效的是检查触发条件和高价值权限。尤其是公开实例、允许自助注册的实例，以及对外提供 OAuth2、webhook、仓库导入、服务端 hook 能力的实例。

可以先做一张很短的自查表：

检查项建议动作现实取舍
开放注册非必要就关闭；必要时加审批、邮件域限制或人工审核会降低社区加入便利性，但能减少攻击入口
非默认配置逐项复核近期改过的安全相关配置需要管理员熟悉配置历史，不能只看默认文档
OAuth2 应用清理不用的应用，收窄权限，检查回调地址可能影响第三方集成，需要提前通知维护者
访问令牌轮换高权限 token，删除长期不用的 token会打断部分自动化任务，要安排窗口
webhook / hook限制高风险 hook 能力，核查外连目标可能影响 CI/CD 流程，需要逐项替代
维护者账户强制 MFA，检查管理员和组织 owner 列表对小项目最有用，成本也最低

对依赖 Forgejo 或 Codeberg 等服务的项目维护者，短期重点是供应链信任。

你不一定能控制平台实例，但可以控制项目侧权限。比如减少长期有效 token，确认 release 权限在谁手里，检查最近新增的维护者、OAuth 授权和 webhook。小项目尤其要看这几项，因为它们往往没有专职安全人员。

如果团队正在采购或迁移代码托管方案，可以把决策往后压一压。不是因为 Forgejo 一定不可用，而是因为现在缺少三个关键信息：受影响版本范围、官方缓解建议、完整审计结果。

接下来该看的变量很具体，不是泛泛地“关注后续”。

变量为什么重要如果迟迟没有
Forgejo 维护方是否发布安全公告用户需要知道风险边界和缓解动作管理员只能靠猜，迁移团队应放慢
是否覆盖认证、OAuth2、hook、注册和配置面审计原文指向多类问题，不像单点 bug零散补丁难以恢复信任
主要公共实例是否调整开放注册和高风险功能公开实例最容易被扫和试探项目维护者要减少对平台侧权限的依赖
是否说明版本范围和配置条件管理员需要判断自己是否暴露无法判断时，按较高风险处理

我不太买账的是一种轻飘飘的说法：开源项目出了问题，大家一起修就好。

当然要修。但代码托管不是普通工具。它管的是别人修复世界的入口。这个入口一旦失守，后面的项目、依赖、发布包和用户都会被拖进去。

回到开头那件事：一晚审出多类问题，未必能证明 Forgejo 已经不安全到不可使用。但它至少说明，在承接 Fedora 这类社区迁移之后，Forgejo 需要拿出更硬的安全治理证据。

信任可以给，不能白给。