最近，一个消息震惊开源社区：在 github 上删掉的内容、私有存储库的数据都是可以永久访问的，而且这是官方故意设计的。
开源安全软件公司 Truffle Security 在一篇博客中详细描述了这个问题。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 免费无限量使用 DeepSeek R1 模型☜☜☜
Truffle Security 引入了一个新术语：CFOR（Cross Fork Object Reference）：当一个存储库 fork 可以访问另一个 fork 中的敏感数据（包括来自私有和已删除 fork 的数据）时，就会出现 CFOR 漏洞。
与不安全的直接对象引用类似，在 CFOR 中，用户提供提交（commit）哈希值就可以直接访问提交数据，否则这些数据是不可见的。
以下是 Truffle Security 博客原文内容。
访问已删除 fork 存储库的数据
想象如下工作流程：
在 GitHub 上 fork 一个公共存储库；
将代码提交到你的 fork 存储库中；
你删除你的 fork 存储库。
那么，你提交给 fork 的代码应该是不能访问了对吧，因为你把 fork 存储库删除了。然而它却永久可以访问，不受你控制。
如下视频所示，fork 一个存储库，向其中提交数据，再删除 fork 存储库，那么可以通过原始存储库访问「已删除」的提交数据。
这种情况普遍存在。Truffle Security 调查了一家大型 AI 公司 3 个经常被 fork 的公共存储库，并从已删除的 fork 存储库中轻松找到了 40 个有效的 API 密钥。
访问已删除存储库的数据
考虑如下工作流程：
你在 GitHub 上有一个公共存储库；
用户 fork 你的存储库；
你在他们 fork 后提交数据，并且他们从不将其 fork 存储库与你的更新同步；
你删除整个存储库。
那么，用户 fork 你的存储库后你提交的代码仍然可以访问。
GitHub 将存储库和 fork 存储库储存在存储库网络中，原始「上游」存储库充当根节点。当已 fork 的公共「上游」存储库被「删除」时，GitHub 会将根节点角色重新分配给下游 fork 存储库之一。但是，来自「上游」存储库的所有提交仍然存在，并且可以通过任何 fork 存储库访问。
这种情况不是个例，上周就发生了这样一件事情：
Truffle Security 向一家大型科技公司提交了一个 P1 漏洞，显示他们意外地提交了一名员工 GitHub 帐户的密钥，而该帐户对整个 GitHub 机构拥有重要访问权限。该公司立即删除了存储库，但由于该存储库已被 fork，因此仍然可以通过 fork 存储库访问包含敏感数据的提交，尽管 fork 存储库从未与原始「上游」存储库同步。
也就是说，只要存储库有至少一个 fork 存储库，那么提交到公共存储库的任何代码都可以永久访问。
访问私有存储库数据
考虑如下工作流程：
你创建一个最终将公开的私有存储库；
创建该存储库的私有内部版本（通过 fork），并为不打算公开的特征提交额外的代码；
你将你的「上游」存储库公开，并将你的 fork 存储库保持私有。
那么，私有特征和相关代码则可供公众查看。从你创建工具的内部 fork 存储库到开源该工具之间提交的任何代码，这些提交都可以通过公共存储库访问。
在你将「上游」存储库公开后，对你的私有 fork 存储库所做的任何提交都是不可见的。这是因为更改私有「上游」存储库的可见性会导致两个存储库网络：一个用于私有版本，一个用于公开版本。
不幸的是，该工作流程是用户和机构开发开源软件时最常用的方法之一。因此，机密数据可能会无意中暴露在 GitHub 公共存储库上。
如何访问数据？
GitHub 存储库网络中的破坏性操作（如上述 3 个场景）会从标准 GitHub UI 和正常 git 操作中删除提交数据的引用。但是，这些数据仍然存在并且可以访问（commit hash）。这是 CFOR 和 IDOR 漏洞之间的联系。
commit hash 可以通过 GitHub 的 UI 进行暴力破解，特别是因为 git 协议允许在引用提交时使用短 SHA-1 值。短 SHA-1 值是避免与另一个 commit hash 发生冲突所需的最小字符数，绝对最小值为 4。所有 4 个字符 SHA-1 值的密钥空间为 65536 (16^4)。暴力破解所有可能的值可以相对容易地实现。
有趣的是，GitHub 公开了一个公共事件 API 端点。你还可以在由第三方管理的事件存档中查询 commit hash，并将过去十年的所有 GitHub 事件保存在 GitHub 之外，即使在存储库被删除之后也是如此。
GitHub 的规定
Truffle Security 通过 GitHub 的 VDP 计划将其发现提交给了 GitHub 官方。GitHub 回应道：「这是故意设计的」，并附上了说明文档。
说明文档：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
Truffle Security 赞赏 GitHub 对其架构保持透明，但 Truffle Security 认为：普通用户将私有和公共存储库的分离视为安全边界，并且认为公共用户无法访问私有存储库中的任何数据。不幸的是，如上所述，情况并不总是如此。
Truffle Security 得出的结论是：只要一个 fork 存储库存在，对该存储库网络的任何提交（即「上游」存储库或「下游」fork 存储库上的提交）都将永久存在。
Truffle Security 还提出一种观点：安全修复公共 GitHub 存储库上泄露密钥的唯一方法是通过密钥轮换。
GitHub 的存储库架构存在这些设计缺陷。不幸的是，绝大多数 GitHub 用户永远不会理解存储库网络的实际工作原理，并且会因此而降低安全性。
原文链接：https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
