Cross Fork Object Reference (CFOR) Vulnerability: Access to Deleted and Private GitHub Repository Data

Introduction

Recent research by Truffle Security discovered that deleting data in a GitHub repository often does not actually remove it, allowing anyone to retrieve the data later. This finding shocked the open‑source community because GitHub hosts billions of repositories and serves as the world’s largest code‑hosting platform.

Definition of CFOR

The researchers coined the term Cross Fork Object Reference (CFOR) to describe a situation where a fork can access sensitive data from another fork—including data from private or deleted forks—by referencing a commit hash directly.

Accessing Deleted Fork Data

When a user forks a public repository, makes commits, and then deletes the fork, the commits remain reachable through other forks in the repository network. Even after the original fork is deleted, the commit objects persist and can be accessed using the commit SHA‑1 hash.

Accessing Private Repository Data

A similar issue occurs with private repositories that are later made public. If a private fork contains internal code or secrets, those commits can still be accessed via the public upstream repository’s network, effectively exposing private data.

How to Retrieve the Data

Anyone who knows—or can guess—a commit hash can navigate directly to the commit using the endpoint https://github.com/<user/org>/<repo>/commit/<commit_hash> . GitHub displays a warning banner indicating that the commit does not belong to any branch of the current repository, but the data is still viewable.

Short SHA‑1 hashes (as few as four characters) are sufficient for brute‑force attacks because the Git protocol accepts abbreviated hashes. For example, the commit 07f01e8337c1073d2c45bb12d688170fcd44c637 can be accessed via https://github.com/trufflesecurity/trufflehog/commit/07f01e .

GitHub Policy Response

Truffle Security reported the findings to GitHub through its Vulnerability Disclosure Program. GitHub responded that the behavior is a deliberate design decision and may be tightened in the future, but no immediate changes were announced.

Implications

Any fork that exists preserves all commits in the repository network forever.

Most GitHub users are unaware of this architecture, leading to a false sense of security.

Secret‑scanning tools need to consider the entire repository network, not just the current repository.

The issue is not limited to GitHub; other version‑control platforms may have similar vulnerabilities.

Recommendations

Rotate secrets immediately after exposure, as deletion does not guarantee removal.

Developers should treat forks as part of the attack surface and avoid committing sensitive data to any fork.

Consider using short‑lived credentials and enforce strict access controls on private repositories.