普通用户往往认为，私有仓库与公共仓库之间存在着明确的安全边界，私有仓库中的数据理应无法被公共用户访问。然而，在GitHub这一广泛使用的平台上，这一认知并不总是正确的。实际上，即便删除了仓库或其中的分叉，提交的数据也并非真正被销毁。

Truffle Security的研究团队发现，已删除的GitHub代码仓库（无论公开还是私有）及其已删除的副本（即分叉）仍有可能持续存在。研究员Joe Leon在一份咨询报告中指出，这种通过API密钥等方式继续访问已删除仓库中数据的情况，实际上构成了一种安全风险。他为此创造了一个新术语“跨分叉对象引用（CFOR）”来描述这一漏洞。

Leon解释说，CFOR漏洞允许某个代码仓库的分叉访问另一分叉的敏感数据，这包括来自私有及已删除分叉的数据。为了证明这一点，Truffle Security的研究人员创建了一个代码仓库，对其进行分叉，并展示了在删除初始仓库之后，未与分叉同步的数据如何通过分叉实现访问。

这一发现引发了广泛的讨论，许多用户呼吁GitHub采取行动。一个形象的解释是：如果你分叉了一个上游仓库并将其设置为私有，在这个私有分叉中提交了一些敏感数据，然后删除了那个提交，但这些提交仍然可以从上游仓库中访问到。

Leon透露，这种情况源于他们向一家大型科技企业提交的严重漏洞报告。该报告涉及一个员工GitHub账户的私钥，该账户在组织内拥有广泛的访问权限。私钥被公开提交到了GitHub代码仓库，尽管后来删除了相应仓库，但由于该仓库已被分叉，敏感数据仍然可以通过分叉访问到。

更令人担忧的是，Truffle Security的研究人员在审查了多家大型AI公司的公共代码仓库后，从已删除的分叉中找到了40个仍然有效的API密钥。然而，GitHub却将CFOR视为一种合法机制，而非严重问题。他们表示，这是一项有意为之的设计，且效果符合预期。

Truffle Security的联合创始人兼CEO Dylan Ayrey指出，这个问题实际上与“悬空提交”有关，这是git系统的一个概念。悬空提交可以存在于任何git平台中，包括GitHub。即使删除了分支，提交本身也不会从仓库的对象数据库中删除。只要掌握能够直接访问这些内容的标识符，就可以正常下载相关数据。

Ayrey还提到，GitHub允许用户通过分叉下载悬空提交，只要拥有标识符的一部分，就可以从作为初始推送目标的仓库处下载它们。这意味着，即使删除了父提交，提交仍然可以被推送，并且允许通过子提交进行下载。

在被问及这一漏洞可能带来的风险时，Ayrey表示，GitHub的事件归档记录了所有的公开操作，这可以用于对科技企业的行为进行取证调查。如果科技企业删除了代码，特别是故意删除了某些内容，这可能意味着存在某些问题，如密钥或密码的泄露、机器学习数据集的意外上传等。

对于GitHub的回应，Ayrey认为他们应该重新考虑自己的立场。普通用户仍然希望在数据安全方面能够明确区分公共和私有仓库，并认为删除操作应该能够实际清理掉提交数据。

最后，对于这一问题的解决办法，专家建议立即更换可能已经泄露的密钥，并检查其是否被不当使用过。这是基本的事件响应措施，以确保数据安全。