Understanding GitHub's CFOR Vulnerability

When I wrote my first post for juniors about mistakes in Git, titled "Why You Should Keep Your API Keys Secure," I received some great advice from a very experienced developer. I want to share it with you because it highlights an important risk that many people don’t know about when using GitHub: Cross Fork Object Reference (CFOR). This issue can expose your private and deleted data, making it crucial to understand.

What is CFOR?

CFOR is a problem that occurs when one fork (a copy) of a repository can access data from another fork, including private and deleted data. If someone knows the commit hash (a unique code that identifies each change), they might be able to see information that should not be available anymore. This is a significant security risk for anyone using GitHub for important projects. Let's have a look at the sheme below.

How does it work?

Here are a few examples to help explain how CFOR can expose data:

1. Accessing Deleted Forks: Imagine you create a fork of a public repository, make some changes, and then delete that fork. You might believe that all your data is gone. However, because of CFOR, that data can still be accessed through the original repository. It means that once something is committed, it can stick around longer than you expect.
2. Deleted Repositories: Suppose you have a public repository, and someone makes a fork of it. If you delete the original repository, you might think everything is deleted. But any changes made to that repository are still accessible through the fork. GitHub keeps this data available, even if the original is gone.
3. Private Repositories: If you start with a private repository, fork it, and make changes that you want to keep private, you might think that data will stay hidden. However, if you later make the original repository public, some of your private changes could still be seen. This happens because of how GitHub manages the relationship between repositories and forks.

Why should you care?

The way GitHub organizes repositories is great for collaboration, but it can also lead to unintentional data exposure. If you’re working on sensitive projects, you need to be aware that some data might still be accessible even after you delete it. Here are a few things to keep in mind:

• Think before you commit: Always be cautious about what information you include in your commits, especially if you might later make a repository public.
• Understand data visibility: Know that once data is committed to a public repository, it can remain accessible indefinitely if any forks exist.
• Use secret scanning tools: Consider using tools that help identify sensitive information in your code, like API keys or passwords, before pushing your changes.

Conclusion

CFOR is a crucial issue for anyone using GitHub. By understanding how data can persist even after deletion, you can take steps to protect your sensitive information. Always be mindful of what you share on GitHub, and make sure you keep your data secure.