Github - You Can View Deleted Private Fork Data

GitHub’s fork and repository-network design can leave commit data accessible even after a repository or fork is deleted—meaning secrets embedded in commits may remain retrievable if someone knows (or can guess) the commit hash. The practical risk is a cross-fork object reference (C4) style issue: one fork can access sensitive data from another fork’s commit history, including commits that were supposed to disappear when the fork or upstream repo was removed.

A core workflow illustrates the problem. A user forks a public repository, adds a file like secrets.py containing “secret” content, commits it, and then deletes the fork. Even after deletion, the commit’s content can still be pulled from the original repository network by using the commit SHA. In the demo, refreshing the original repository page returns a 404 for the deleted fork, yet the commit remains reachable when the SHA from the secret commit is inserted into the appropriate GitHub URL pattern. The underlying reason is that Git stores objects (commits, trees, blobs) in a content-addressed way; deleting a ref doesn’t necessarily erase the underlying objects immediately, and GitHub’s repository-network relationships can keep those objects reachable.

The transcript also ties this behavior to Git internals and GitHub’s UI/URL mechanics. Git’s “plumbing” (including commands like git cat-file and the idea of reflog) helps explain why data can persist locally and why refs can be misleading. On GitHub, the key enabler is that commit hashes can be referenced directly. Users typically only need a short SHA in the interface—often as few as four characters in some cases—because GitHub and the Git protocol allow short hashes to resolve to full commits. That creates a brute-force angle: short SHA values expand the search space enough that attackers can attempt guesses through the UI until a valid commit is found.

The discussion goes further with scale and methodology claims. One example cited: researchers reportedly surveyed forked public repositories from a large AI company and found a large number of valid API keys originating from deleted forks. Another scenario: when an upstream repository is deleted, GitHub can reassign the “root node” of the repository network to a downstream fork, while commits from the original upstream remain accessible via any fork in that network. That means “deleting the repo” may not be equivalent to “removing the commit history from reach.”

For private-to-public release pipelines, the transcript describes a related visibility split. Commits made in a private fork before a project becomes public can become accessible through the public repository network if the commit objects remain reachable. The takeaway is blunt: remediation for leaked secrets on GitHub is effectively key rotation, not relying on deletion, squashing, or UI removal.

Even legal and compliance questions surface—such as how “deleted” data interacts with privacy requests—alongside the security framing that the only reliable fix is to treat leaked credentials as compromised and rotate them immediately.