Home Security Research on the GitHub Dataset Shows Millions Possibly Vulnerable to RepoJacking

Research on the GitHub Dataset Shows Millions Possibly Vulnerable to RepoJacking

GitHub Dataset Research Reveals Millions Potentially Vulnerable to RepoJacking-bhavintechglobal
Ref:- aquasec

of GitHub repositories potentially face the risk of RepoJacking, according to
recent research conducted by Aqua Nautilus. This study sheds light on the
extent of RepoJacking, a vulnerability that, if exploited, could result in the
execution of malicious code within organizations’ internal environments or
their customers’ environments. During our research, we came across a vast
source of data that allowed us to sample a dataset and identify several highly
popular targets.


Notable companies like Google and Lyft, as well as others who chose to stay unknown, were among the repositories we discovered to be vulnerable to this assault. We quickly alerted these organisations to the vulnerability, and they immediately took steps to reduce the risks. In this blog, we will demonstrate how
attackers can exploit this vulnerability at scale, sharing the proof of concept
(PoC) we ran on popular repositories.

Our research, in contrast to earlier studies, emphasises the security implications and seriousness of this database if it is compromised by attackers. It contains a large number of top-notch targets vulnerable to RepoJacking. We explore the exploitation scenarios of this attack in more detail in this blog, using actual instances to demonstrate each scenario.

GitHub Dataset Research Reveals Millions Potentially Vulnerable to RepoJacking-bhavintechglobal

What is RepoJacking?

A supply chain assault called GitHub RepoJacking, also known as dependency repository hijacking, gives attackers the ability to seize control of dependencies found in GitHub projects or potentially the entire projects themselves. This control allows them to execute malicious code on those who
utilize these projects.

RepoJacking occurs when a GitHub user or
organization changes its name. To prevent code dependencies from breaking,
GitHub establishes a link between the old name and the new name, redirecting
the old name to the new one. 
For instance, if my code is intended to use dependencies from a different GitHub project (or the entire project) located at “github.com/username_A/repo_A,” and the account’s owner changes the account’s name to “github.com/username_B/repo_A,” GitHub’s feature links the dependencies to the new account (‘github.com/username_B/repo_A’), even if your code still

Initially, this feature is beneficial for
However, the previous username becomes accessible, making it usable by anyone. The aforementioned link is broken when someone creates both “username_A” and the repository “repo_A,” requiring any project that depended on “github.com/username_A/repo_A” to download dependencies from the repository once more. now owned and controlled by someone else. Attackers are aware of
this vulnerability and actively exploit it to carry out supply chain attacks.

GitHub Dataset Research Reveals Millions Potentially Vulnerable to RepoJacking

We can identify two plausible RepoJacking scenarios:

  1. Repository owner’s username changed: When a repository owner changes their username, everyone that downloads dependencies from the previous repository will see a link between the previous name and the new name. Anybody may, however, create the previous account and break this link.
  2. Mergers and Acquisitions: In this case, the original account is terminated and the repository ownership is transferred to another user as a result of mergers or acquisitions. Dependency downloaders will be redirected to the new account if they use the old repository. However, anyone may still make the old username and break this relationship by doing so.

RepoJacking Restrictions and Bypasses:

There are certain restrictions, known as retired names, that limit the capabilities of attackers to claim the old repository name. These limitations, however, only apply to well-liked repositories that were well-liked before the name change. Recent studies have uncovered several ways to get around these limitations, allowing attackers to access any repository they choose. Additional details on these limitations and workarounds are provided in Appendix B. As a result, businesses shouldn’t use retired names as a security measure. In this research, a vulnerable repository is defined as one that gets redirected, with the organization name no longer in existence.

Are You Exposed to RepoJacking?

You might be wondering whether you own repositories that are directly or indirectly vulnerable to RepoJacking. The explanation is that there are several opportunities for exposure. There are a few key questions you should ask yourself if you believe you may have been exposed:

  • What do you know about your organization?
  • What were all the GitHub organization names you previously used?
  • Has your company ever been a part of a merger or acquisition?
  • Do any dependencies in your code lead to a GitHub repository that is vulnerable to RepoJacking?
  • Do any instructions (such as documentation, instructions, Stack Overflow answers, etc.) recommend using a GitHub repository that is susceptible to RepoJacking?

As mentioned earlier, the possibilities of exposure are extensive, and depending on the answers to any of these questions, you may discover that your organization is vulnerable.


Please enter your comment!
Please enter your name here