Three eventualities allow GitHub repositories to be hijacked. Linking on to them could lead to malicious code injection; don’t do it.
A discovering throughout a latest shopper engagement brought on us to research the prevalence of dependency repository hijacking which is an obscure vulnerability that permits anybody to hijack a repository if its proprietor adjustments their username. This vulnerability is just like subdomain takeover, trivial to take advantage of, and ends in distant code injection. After analyzing open-source tasks for this difficulty and recursively looking via their dependency graphs, we discovered over 70,000 impacted open-source tasks; this contains standard tasks and frameworks from corporations like Google, GitHub, Fb, and lots of others. To mitigate this difficulty, be certain that your challenge doesn’t rely upon a direct GitHub URL, or use a dependency lock file and model pinning.
If you’re acquainted with Repo Jacking, leap straight to our Evaluation.

What’s Repo Jacking?
Dependency repository hijacking (aka repo jacking) is an obscure provide chain vulnerability, conceptually just like subdomain takeover, that impacts over 70,000 open-source tasks and impacts every part from net frameworks to cryptocurrencies. This vulnerability is trivial to take advantage of, ends in distant code injection, and impacts main tasks from corporations like Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and lots of others. After first discovering it in a latest engagement, we needed to understand how prevalent this vulnerability was, so we recursively analyzed all open-source tasks and located that this can be very widespread and most definitely impacts you indirectly.
Who’s susceptible?
Each challenge whose compilation is dependent upon dynamically linked code from GitHub repositories is probably susceptible. For a challenge to be susceptible, the next two issues have to occur:
Your code must instantly reference a GitHub repository (often as a dependency).
The proprietor of that repository must then change/delete their username.
When the linked repository proprietor adjustments their username, it turns into instantly out there to be re-registered by anybody. Because of this any challenge that linked again to the unique repository URL has now change into susceptible to distant code injection via dependency hijacking. A malicious attacker can register the outdated GitHub username, recreate the repository, and use it to serve malicious code to any challenge that is dependent upon it.
Must you be involved?
Even when your challenge that has a dependency on a GitHub isn’t susceptible proper now, if the proprietor of one in all its dependencies adjustments their username, that challenge and all different tasks that rely upon the outdated hyperlink change into susceptible to repo jacking. You’ll count on there to be some type of warning when repository adjustments areas, perhaps a “404 – Repository not discovered” type of error, however there’s not. Moreover, there’s one little Github characteristic that makes this vulnerability distinctly extra harmful: Repository Redirects.
‘Repository Redirects’ exacerbate the issue
When a GitHub consumer adjustments both the title of a repository or their username GitHub units up a redirect from the outdated URL to the brand new one; this redirect works for each HTTP and Git requests. This redirect is created any time a consumer adjustments their username, transfers a repository, or renames a repository. The issue right here is that if the unique repository (on this case, “twitter/bootstrap”) is ever recreated, the redirect will break and ship you to the newly created repository.
Instance situation:
The hyperlink factors to the repository “twitter/bootstrap” however will really redirect you to the “twbs/bootstrap” repository.
If ever Twitter modified their GitHub username, anybody might then re-register it, recreate a repository named “bootstrap” and any new request to would go to the newly created repository.
Any challenge that trusted would now begin loading code from this new repository.
Redirection is a handy characteristic because it means your hyperlinks don’t instantly break once you rename your account. Nevertheless it additionally signifies that your challenge can unknowingly change into susceptible to repo jacking. Out of your standpoint, nothing has modified – your code nonetheless compiles the identical, and every part works because it ought to. Nevertheless, your challenge is now susceptible to distant code injection, and you might be none the wiser.
The three Hijack Situations
To get a bit of extra particular, there are technically three alternative ways a repository can change into hijackable:
A GitHub consumer renames their account. That is the most typical approach a repository turns into hijackable since it isn’t unusual for a consumer to rename their account and once they do, every part continues working as anticipated on account of repository redirects.
A Github consumer transfers their repository to a different consumer or group then deletes their account. When a consumer transfers a repository, a redirect is ready up and by deleting their consumer opens it as much as being hijacked by anybody.
A consumer deletes their account. That is the least impactful of the three, because the second the unique consumer deletes their account, any challenge that references it can begin having errors when attempting to fetch the repo.
Be aware: There have been just a few circumstances (one, two) of attackers re-registering the deleted username between the time the consumer deletes their account and tasks attempt to fetch the repo. This situation has been written about earlier than right here.
GitHub’s Response
We contacted GitHub earlier than publishing this text, they usually knowledgeable us that it is a identified difficulty however that they at present don’t have any plans to vary the way in which redirection or username reuse works. They’ve supplied some mitigations to this drawback for some standard repositories by disallowing re-registering the names of repositories which have greater than 100 new clones within the week main as much as their deletion, as outlined right here. This does present a point of safety however will not be a foolproof answer as many smaller repositories don’t meet this criterion however could be nonetheless be depended upon by standard tasks. As such, builders that needed to make use of them wanted to hyperlink on to GitHub.
The foundation drawback right here will not be a lot that GitHub permits redirects and username reuse, however moderately that builders are pulling their code from unsafe areas. GitHub can’t police builders who’re utilizing their service for unintended functions. There are numerous package deal managers out there (in actual fact, GitHub themselves has one) constructed to unravel the issue of distant code dependencies, and builders have the accountability of making certain that they load their code from safe areas.
Now the following query that involves thoughts is, “How widespread is that this actually?”. It seems that sifting via all open supply tasks, compiling their dependencies, discovering all hijackable repositories, and establishing a dependency graph of susceptible repositories will not be simple. So, right here is how we did it.

Step 1 – Knowledge Assortment
One of many hardest components of performing large-scale evaluation of open supply software program is the preliminary information assortment. Discovering an updated, correct, and simply searchable index of all of the open-source tasks is tough. We primarily used two datasets for this evaluation:
GitHub Exercise DataThis is supplied by Github themselves and is a large dataset that features over 2.eight million repositories, together with all of their recordsdata and contents; all the dataset is over 3TB value of content material. Conveniently, it’s hosted as a public BigQuery dataset on the Google Cloud Platform (GCP), which signifies that we will use BigQuery to run SQL instructions over all the dataset from inside GCP itself, and we don’t should obtain all the 3TB+ file.To really carry out the search, we generated a regex that catches any Github URL or different frequent Github dependency hyperlink codecs reminiscent of github:username/reponame. Utilizing this regex, we have been capable of extract the repository, file title, and file contents for every file that accommodates a reference to a GitHub hyperlink. This shrunk our search house down from 3TB+ to a extra manageable 4GB. This filtered dataset included Four million distinctive GitHub hyperlinks and over 700 hundred thousand totally different Github customers. is an open-source challenge that goals to mixture all of the dependency from multi totally different packager managers right into a graph-like dataset. That is superb since not solely does it do all of the heavy lifting for us in linking what depends on what, however moreover they make all the dataset out there to obtain totally free. Uncompressed, this dataset is over 100GB+ however could be loaded instantly right into a database for simpler processing.
It was necessary that we use the 2 datasets as a result of each is sweet at various things. The “Github Exercise Knowledge” dataset allowed us to seek out each doable Github hyperlink referenced in a repository, even when it isn’t being utilized in an apparent place like a package deal supervisor manifest. A few of the most attention-grabbing findings weren’t essentially direct code dependencies. We regularly discovered Github URLs used instantly in a bash script to clone a repository or a docker picture that will pull a repository from Github when constructed.
Instance set up script; the GitHub hyperlinks can be found to be registered by anybody.
One other frequent discovering was hijackable repositories as Git submodules, one thing that will have been missed by customary dependency evaluation. Conversely, the dataset was an already cleaned, filtered, and formatted dataset th allowed us to construct a dependency graph and simply assess the extensiveness of this vulnerability. Collectively, these datasets gave us a extra full view of the general influence of this vulnerability to open supply tasks.
Step 2 – Clear Up
Now that we had collected all this information, we would have liked to sanitize and normalize it. This was a sizeable effort since we would have liked to account for the totally different codecs of every package deal supervisor. Moreover, we needed to take away any hyperlinks that weren’t really getting used as a dependency. Many of those hyperlinks have been utilized in feedback, for instance, one thing like: //code impressed from, or in documentation textual content recordsdata. Since we have been primarily involved with the opportunity of code injection, we trimmed off something that was not going for use instantly by the code. This left us with a bit of over 2 million distinctive GitHub hyperlinks that have been referenced by recordsdata in significant methods.
Step 3 – Hijackable Usernames
Now that we now have a clear(er) listing of tasks that instantly rely upon a GitHub hyperlink, we would have liked to seek out which customers have been at present unregistered. At this level, we had about 650ok Github usernames that we needed to type via. Utilizing the GitHub API we might test to see if a username exists, however we have been charge restricted to five,000 requests an hour, which signifies that it could have taken us over 5 days to test all of the usernames. With a bit of little bit of intelligent logic and the GitHub GraphQL API, we have been capable of deliver that all the way down to a bit of over 2 hours to scan all 650ok customers.
So, what are the outcomes? We discovered that about 7% (about 50ok) of the usernames we collected are unregistered. We actually weren’t anticipating the quantity to be so excessive. We thought that lower than 1% of the usernames we discovered have been going to be hijackable. Apparently, individuals get uninterested in their usernames way over anticipated.
Step 4 – Susceptible Initiatives
As soon as we had all of the hijackable usernames, it was only a query of doing a reverse search on our dataset for each challenge depending on a repository owned by a type of usernames. After some additional filtering and elimination of false positives, we discovered a complete of 18,000 tasks instantly susceptible to repository hijacking. These tasks have a mixed GitHub begin depend of over 500,000 stars and embody tasks in nearly each language from a few of the largest open supply organizations.
This quantity alone is terrifying, however fashionable codebases should not big monolith residing inside single repositories. As a substitute, they rely and rely upon many different tasks for performance. That is nice for maintainability and reusability, however it signifies that a vulnerability in a single standard dependency can significantly influence many tasks down the dependency chain. Successfully any challenge that’s depending on one of many 18,000 instantly susceptible tasks is itself additionally susceptible.
Step 5 to ∞ – Dependency Evaluation
Now that we had a listing of instantly susceptible tasks, we used that together with our earlier dataset to carry out a dependency graph taint search and discover each challenge that is dependent upon a susceptible repo of their provide chain. For this evaluation, we included regular dependencies and fewer apparent ones reminiscent of improvement dependencies or dependencies which aren’t in the primary package deal manifest file. If one in all these auxiliary dependencies is susceptible to repo sniping, it’d take a bit of longer for the influence to propagate up the dependency chain since it’d solely occur when the builders publish a brand new model. With that in thoughts, we started our taint evaluation.
Because of the risk that the listing of susceptible tasks grows exponentially out of hand, we slowly walked the graph one depth layer at a time. Between every go, we manually went via the outcomes and trimmed off any apparent false positives to attenuate error propagation and guarantee our outcomes didn’t get crammed with false positives.
We needed to cease after 5 passes.
Up till 5 passes, the information was rising predictably, and every spherical of search was taking an affordable period of time, however the second we reached a depth of 6, the information began rising uncontrollably. Trying on the outcomes for the fifth go, the explanation grew to become clear; we had reached a number of large frameworks which are foundational and trusted by 1000’s of different tasks.
This was sufficiently deep for us to understand the influence of this vulnerability. General, Safety Innovation discovered over 70,000 impacted tasks, with a grand complete mixed GitHub star depend of over 1.5 million; that’s extra stars than the mixed complete of the highest eight largest GitHub repositories ever. It’s exhausting to precisely measure, however we estimate that these tasks have a mixed complete of no less than 2 million each day downloads.
Impacted tasks embody repositories from large organizations reminiscent of Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and lots of others. The whole lot from small private consumer tasks to standard net frameworks utilized by lots of of 1000’s of organizations is affected. It’s also attention-grabbing to notice simply what number of various kinds of software program this impacts. We discovered susceptible router firmware, video games, crypto wallets, cell apps, and lots of different distinctive tasks.
Now that we perceive how impactful and widespread this vulnerability is, it is very important know what remediation choices can be found to guard your individual challenge’s provide chain.
Don’t Hyperlink On to GitHub Repositories
That is the obvious one: GitHub repositories should not, and have by no means claimed to be, an alternative to a package deal supervisor. There aren’t any ensures that GitHub hyperlinks are static, they usually shouldn’t be used as direct code dependencies. Utilizing a devoted package deal supervisor has many benefits, each from a usability and safety perspective, and may all the time be most well-liked over instantly linking to a repository. Nevertheless, do notice that you could be nonetheless be susceptible to repo jacking if one in all your dependencies themselves instantly hyperlinks to a GitHub URL even should you test every of your transitive dependencies for direct hyperlinks, a type of dependencies would possibly nonetheless have a hidden dependency to a GitHub repo. We’ve seen this usually with construct scripts, which fetch code instantly from a developer’s repository, or inside testing code. Whether it is susceptible to a hidden repository hijacking, the following time that dependency will get up to date, it might include malicious code that then makes its approach into your utility.
Model Pinning and Lock Information
One other approach to assist mitigate this vulnerability is thru model pinning and lock recordsdata. Model pinning is when a particular model is included with a dependency to make sure that solely that model will get downloaded. Within the context of GitHub hyperlink dependencies, that is usually a SHA1 git commit hash, which is included to instruct your package deal supervisor software to solely obtain that particular commit of a git repository. The purpose with that is that even when that repo will get hijacked, a malicious attacker wouldn’t have the ability to modify the code with out additionally modifying the commit hash. You may also model pin a dependency to a particular department or tag, however there’s nothing to cease a malicious consumer from updating that tag or department, so it doesn’t present any safety in opposition to repo jacking.
A lock file is a file made by your package deal supervisor software that features a listing of version-pinned dependencies to make sure that subsequent time somebody tries to construct that challenge, they obtain the very same package deal and model specified within the lock file. Lock recordsdata may generally embody an integrity hash of the downloaded package deal to additional guarantee its authenticity.
Model pinning and lock file implementations are package deal supervisor particular, however most huge packager managers help these options. That being stated, they’re removed from foolproof.   In actual fact, whereas we have been conducting this analysis, we managed to bypass most main package deal supervisor’s model pinning and lock recordsdata. Keep tuned for a future weblog put up the place we element these points in depth.
Vendoring is the act of downloading all of your dependencies beforehand and together with them in your repository. This has the benefit that your repositories are fully self-contained with the code wanted to run them, and it additionally helps defend you in opposition to repo jacking. Since all of your dependencies are already downloaded, it is sort of a lock file that additionally contains the content material to your dependencies. Even when a type of dependencies will get hijacked, you could have already downloaded the code you want. The caveat right here is that you just would possibly nonetheless change into susceptible the following time you replace your dependencies if a type of dependencies has been hijacked. Many builders simply replace all their dependencies when their package deal supervisor tells them to, with out wanting that the precise adjustments that have been made.   In these circumstances, vendoring supplies little or no safety because it solely works should you maintain a detailed eye on dependency upgrades.
Hopefully, this text helped shed some gentle on the impacts of dependency repository hijacking and permit tasks to raised safe their dependencies provide chains. The proliferation of COTS, third celebration software program, and open supply will proceed to increase, and together with it, so will the variety of assaults concentrating on them. Though the usage of third celebration dependencies get options out the door faster and reduces improvement time, it’s crucial that you just scrutinize them the identical approach you do your individual code – maybe much more so.