GitHub 的隐藏陷阱：已删除和私有仓库数据仍可被公开访问

GitHub 中存在跨 Fork 对象引用（CFOR）漏洞，导致已删除的 fork、仓库甚至私有仓库中的提交数据仍然可被公开访问，且永久有效。

原文链接及背景

本文由 Truffle Security 的研究人员发表于 2024 年 7 月 24 日，在 Hacker News 上获得 1983 分和 374 条评论。原英文文章链接：Anyone can Access Deleted and Private Repository Data on GitHub

注意：文章发布后，Truffle Security 更新了其开源工具 TruffleHog，使其能够自动发现所有此类“已删除或私有”的提交，详见后续博文：https://trufflesecurity.com/blog/trufflehog-now-finds-all-deleted-and-private-commits-on-github

核心发现：CFOR – 跨 Fork 对象引用

在 GitHub 上，任何人都可以访问来自已删除的 fork、已删除的仓库，甚至私有仓库的提交数据。这些数据一旦产生，就会永久保留，即便用户主动删除也无法移除。GitHub 知晓这一行为，并且是有意设计的。这种缺陷极大规模地扩大了攻击面，作者为此提出了一个全新的术语：跨 Fork 对象引用（Cross Fork Object Reference，CFOR）。

CFOR 漏洞的定义：当一个仓库的一个 fork 能够访问来自另一个 fork 的敏感数据（包括私有 fork 和已删除 fork 的数据）时，就存在 CFOR。这与不安全的直接对象引用（IDOR）类似——用户只需提供提交哈希（commit hash）即可直接访问本应不可见的提交数据。

案例一：访问已删除 fork 中的数据

场景重现：

1. 用户 fork 了一个公共仓库。
2. 用户向其 fork 中提交了代码（可能包含机密信息，如 API 密钥）。
3. 用户删除了该 fork。

按照常理，删除 fork 后，其中的代码应当无法再被访问。但实际并非如此：数据依然存在且永久可访问，并且用户完全无法控制。

攻击者可以通过原始仓库访问到这些“已删除”的提交数据。虽然乍看之下需要知道具体的 commit hash 才能访问，但作者指出，commit hash 是可以通过多种手段被发现的，因而这种保护措施形同虚设。

数据暴露的普遍性：作者仅调查了少数（3 个）大型 AI 公司常用的公共仓库，就轻松找到了 40 个有效的 API 密钥，全部来自这些仓库的已删除 fork。典型的用户错误模式如下：

• 克隆（fork）仓库。
• 将 API 密钥硬编码在示例文件中。
• 执行工作。
• 删除 fork，以为数据也随之消失了。

案例二：访问已删除仓库中的数据

场景重现：

1. 用户有一个公共仓库。
2. 另一个用户 fork 了这个仓库。
3. 在 fork 创建之后，用户向原始仓库提交了新的代码（fork 从未同步过这些更新）。
4. 用户随后删除了整个原始仓库。

结果：用户删除仓库后，提交的新代码依然可以通过其分支（fork）访问，尽管该 fork 从未同步过这些更新。

原因：GitHub 将仓库和 fork 存储在同一个 仓库网络（repository network） 中，原始“上游”仓库作为根节点。当一个公共“上游”仓库被删除，但已被 fork 过时，GitHub 会将根节点角色重新分配给其中一个下游 fork。但所有来自上游仓库的提交仍然存在，并可通过任何 fork 访问。

作者特地提到，这并非边缘情况。就在文章发布的前一周，他们向一家大型科技公司报告了一个 P1 级漏洞：一名员工不小心提交了其 GitHub 账号的私钥，该账号对整个 GitHub 组织有重要权限。公司随即删除了相关仓库，但由于仓库已被 fork，作者仍然可以通过一个从未同步过的 fork 访问包含敏感数据的提交。

核心启示：任何提交到公共仓库的代码，只要存在至少一个 fork（无论该 fork 是否同步），该代码就可能被永久访问。

案例三：访问私有仓库中的数据（私有转公共时的泄露）

这是一个非常常见的开源工作流：

1. 用户创建一个计划将来开源的私有仓库。
2. 用户又通过 fork 创建一个私有的内部版本，并向其中添加一些不打算公开的功能代码。
3. 用户将“上游”仓库（即最初的私有仓库）设置为公共，同时保留内部 fork 为私有。

结果：在步骤 2 中提交的所有内部代码，都可以通过公共的“上游”仓库访问到。对于普通用户而言，所有从创建内部 fork 到将上游仓库公开期间进行的提交，都能在公共仓库中查看。

原因：当私有“上游”仓库改变可见性（变为公共）时，GitHub 会将仓库网络拆分为两个：一个是私有版本网络，一个是公共版本网络。但是，在拆分之前产生的所有提交都会归属于公共网络，因此可以从公共仓库中访问。在公开之后对新私有 fork 的提交则不会泄露。

影响：这种“先私有开发、再转公共”的工作流是大量用户和组织开发开源软件的常用方式，直接导致大量机密数据和密钥可能被不经意地暴露在组织的公共 GitHub 仓库中。

如何访问已删除或私有数据？

技术原理：直接访问提交的 commit hash。

当仓库网络发生破坏性操作（如删除 fork、删除仓库、改变可见性）时，GitHub 的常规 UI 和普通 git 操作会移除对这些提交的引用，但这些提交数据本身并未被删除，只需知道 commit hash，任何人都可以直接访问。这正是 CFOR 与 IDOR 的联系：如果你能预测或获得一个哈希，你就可以直接访问本不属于你的数据。

访问方式：GitHub 允许用户通过 https://github.com/<user/org>/<repo>/commit/<commit_hash> 直接导航到任意提交。当提交不属于任何分支时，页面会显示黄色横幅：“此提交不属于该仓库的任何分支，可能属于仓库外的 fork。”但这并不妨碍其内容被查看。

获取 commit hash 的途径：

• 暴力破解：commit hash 是 SHA-1 值。GitHub 的 git 协议支持使用短 SHA-1（最少 4 个字符）来引用提交。4 字符 SHA-1 的空间仅为 65,536（16^4），暴力枚举非常容易。例如，TruffleHog 仓库中的某个提交，完整哈希为 07f01e8337c1073d2c45bb12d688170fcd44c637，但只需访问 https://github.com/trufflesecurity/trufflehog/commit/07f01e 即可。
• 公共事件 API：GitHub 提供了公开的事件 API 端点，可以查询历史事件。此外，还有一个由第三方管理的 GitHub Events Archive，保存了过去十年所有 GitHub 事件，并且独立于 GitHub 存储，即使仓库被删除，这些事件数据依然存在，其中可能包含 commit hash。

GitHub 的官方回应与责任归属

作者通过 GitHub 的漏洞披露计划（VDP）提交了这些发现。GitHub 的回应是：这些行为是有意设计的，并附上了官方文档的链接：当删除仓库或改变可见性时，fork 会发生什么。

作者承认 GitHub 对其架构的透明性，也理解文档已清楚说明这些行为。但关键在于：普通用户并不了解这一机制。多数用户人为地认为删除 fork 或仓库会清除一切数据，而 GitHub 的设计却并非如此。这种信息不对等，使得 CFOR 漏洞成为一个巨大且被忽视的攻击面。

总体影响与安全建议

攻击面：所有使用 GitHub 的组织和个人都面临此风险。任何敏感信息一旦以代码形式提交到 GitHub（无论是私有、内部还是公共仓库），只要存在 fork 网络，就可能被永久暴露。

安全建议：

• 永远不要在 Git 仓库中提交任何敏感信息（密钥、密码、令牌等），无论该仓库是私有还是公共。
• 如果在任何仓库中不小心提交了敏感数据，立即轮换（revoke）相关凭证，而不是简单地删除文件，因为历史提交永远存在。
• 了解 GitHub 的“仓库网络”概念，尤其是在处理跨 fork 数据时。
• 对于开源工作流，应避免在私有 fork 中保留不打算公开的秘密代码；使用分支或受控方式，而不是依赖“删除”来保证安全。

文章所揭示的并不是一个新漏洞，而是一个被广泛忽视的设计缺陷。Truffle Security 希望以“CFOR”一词来提高警惕，促使安全社区重视这一类似 IDOR 的风险模式。