此漏洞是由JOE LEON发表的名为Cross Fork Object Reference（https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github），可以在Github上访问已删除的forks、已删除的仓库甚至私有仓库中的数据。而且漏洞暂时可用并且看来会持续有效很久。GitHub其实是为了设计和用户体验，有意以这种方式进行设计的，具体见最后部分官方回应。
GitHub 上的以下常见工作流：
你分叉了一个公共仓库 将代码提交到分支中
你删除你的分叉
我们测试调查了一家大型 AI 公司的3个常见分叉的公共仓库，并轻松地从已删除的分叉中找到了 40 个有效的 API 密钥，原用户流程是这样的：
分叉存储库
将 API 密钥硬编码到示例文件中
<Do Work> 删除分叉
二.访问已删除的存储库数据
在 GitHub 上有一个公共仓库。
用户分叉仓库。
在他们分叉数据后提交数据（从不将他们的分叉与更新同步）。
删除整个存储库。
在下面的视频中，我们创建一个仓库，对其进行分叉，然后展示在删除原始仓库后，分叉如何仍然可以访问未与分叉同步的数据。
和上面视频类似的问题，我向一家大型科技公司提交了一个 P1 漏洞，显示他们不小心把一名员工的 GitHub 帐户提交了私钥，该帐户对其整个 GitHub 组织具有重要访问权限。虽然他们立即删除了存储库，但由于它已经被分叉了，我仍然可以通过分叉访问包含敏感数据的提交，尽管分叉从未与原始的“上游”存储库同步。
三.访问私有仓库数据
这个例子是以下常见工作流程，用于在 GitHub 上开源新工具：
创建一个私有仓库，该仓库最终将公开。
可以创建该仓库的私有内部版本（通过分叉），并为不打算公开的功能提交其他代码。
你把你的“上游”仓库设为公共，并保持你的分叉是私有的。
在下面的视频中，我们演示了组织如何在维护私有内部分叉的同时开源新工具，然后展示某人如何通过公共版本访问私有内部版本的提交数据。
而且重点是这种工作流程是用户和组织开发开源软件时最常见的方法之一。因此，机密数据和机密可能会无意中暴露在组织的公共 GitHub 仓库上。
真实利用：
作者开源一个新的 TruffleHog 模块的 alpha 版本，该模块枚举了 Cross Fork 对象引用（和已删除的 git 历史记录），然后扫描它们以查找机密。该过程很慢，并且受 GitHub 的速率限制的约束，因为它涉及枚举数千个可能的提交哈希。使用方法如下：
trufflehog github-experimental --repo https://github.com/<USER>/<REPO>.git --object-discovery--object-discovery 要求用户在其环境变量中设置有效的 GitHub 访问令牌 （export GITHUB_TOKEN=ghp_） 或在命令行 （--token ghp_） 上传递它。
利用原理：
如前面3种案例情况下漏洞利用访问方式都是直接访问，但需要哈希值。
通过从标准 GitHub UI 和正常 git 操作中删除提交数据的引用。但是，此数据仍然存在并且可访问（如果知道提交哈希）。这是 CFOR 和 IDOR 漏洞之间的联系 - 如果知道提交哈希，则可以直接访问不适合您的数据。
提交哈希是 SHA-1 值
如果用户知道他们想要查看的特定提交的 SHA-1 提交哈希，他们可以直接导航到端点的该提交：https://github.com/
那么怎么获取这些哈希值呢
GitHub 的回应：
漏洞已经提交了，但Github回应是无影响，如下：
在查看了这个文档之后，发现这明显 GitHub 设计的仓库就是这样工作的，有些只是使用方式错误。
