Three eventualities allow GitHub repositories to be hijacked. Linking on to them might end in malicious code injection; don’t do it.
A discovering throughout a latest consumer engagement induced us to research the prevalence of dependency repository hijacking which is an obscure vulnerability that enables anybody to hijack a repository if its proprietor adjustments their username. This vulnerability is just like subdomain takeover, trivial to use, and ends in distant code injection. After analyzing open-source tasks for this subject and recursively looking by means of their dependency graphs, we discovered over 70,000 impacted open-source tasks; this contains well-liked tasks and frameworks from corporations like Google, GitHub, Fb, and plenty of others. To mitigate this subject, be certain that your mission doesn’t depend upon a direct GitHub URL, or use a dependency lock file and model pinning.
In case you are aware of 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 the whole lot from internet frameworks to cryptocurrencies. This vulnerability is trivial to use, ends in distant code injection, and impacts main tasks from corporations like Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and plenty of others. After first discovering it in a latest engagement, we wished to know the way prevalent this vulnerability was, so we recursively analyzed all open-source tasks and located that this can be very widespread and more than likely impacts you in a roundabout way.
Who’s susceptible?
Each mission whose compilation relies on dynamically linked code from GitHub repositories is doubtlessly susceptible. For a mission to be susceptible, the next two issues must occur:
Your code must straight reference a GitHub repository (normally 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 accessible to be re-registered by anybody. Which means that any mission that linked again to the unique repository URL has now change into susceptible to distant code injection by means of dependency hijacking. A malicious attacker can register the previous GitHub username, recreate the repository, and use it to serve malicious code to any mission that relies on it.
Do you have to be involved?
Even when your mission that has a dependency on a GitHub isn’t susceptible proper now, if the proprietor of one in every of its dependencies adjustments their username, that mission and all different tasks that depend upon the previous hyperlink change into susceptible to repo jacking. You’d anticipate there to be some sort of warning when repository adjustments areas, possibly a “404 – Repository not discovered” sort of error, however there may be not. Moreover, there may be one little Github characteristic that makes this vulnerability distinctly extra harmful: Repository Redirects.
‘Repository Redirects’ exacerbate the issue
When a GitHub person adjustments both the identify of a repository or their username GitHub units up a redirect from the previous URL to the brand new one; this redirect works for each HTTP and Git requests. This redirect is created any time a person 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 mission that relied on 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. However it additionally signifies that your mission can unknowingly change into susceptible to repo jacking. Out of your viewpoint, nothing has modified – your code nonetheless compiles the identical, and the whole lot works because it ought to. Nonetheless, your mission is now susceptible to distant code injection, and you’re none the wiser.
The three Hijack Eventualities
To get a little bit extra particular, there are technically three alternative ways a repository can change into hijackable:
A GitHub person renames their account. That is the commonest manner a repository turns into hijackable since it’s not unusual for a person to rename their account and after they do, the whole lot continues working as anticipated resulting from repository redirects.
A Github person transfers their repository to a different person or group then deletes their account. When a person transfers a repository, a redirect is about up and by deleting their person opens it as much as being hijacked by anybody.
A person deletes their account. That is the least impactful of the three, for the reason that second the unique person deletes their account, any mission that references it is going to begin having errors when making an attempt to fetch the repo.
Observe: There have been a couple of instances (one, two) of attackers re-registering the deleted username between the time the person 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, and so they knowledgeable us that it is a recognized subject however that they at present would not have any plans to alter the best way redirection or username reuse works. They’ve offered some mitigations to this drawback for some well-liked 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 some extent of safety however isn’t a foolproof answer as many smaller repositories don’t meet this criterion however may be nonetheless be depended upon by well-liked tasks. As such, builders that wished to make use of them wanted to hyperlink on to GitHub.
The foundation drawback right here isn’t a lot that GitHub permits redirects and username reuse, however fairly that builders are pulling their code from unsafe areas. GitHub can’t police builders who’re utilizing their service for unintended functions. There are lots of bundle managers accessible (in truth, GitHub themselves has one) constructed to resolve the issue of distant code dependencies, and builders have the accountability of guaranteeing that they load their code from safe areas.
Now the subsequent query that involves thoughts is, “How widespread is that this actually?”. It seems that sifting by means of all open supply tasks, compiling their dependencies, discovering all hijackable repositories, and establishing a dependency graph of susceptible repositories isn’t simple. So, right here is how we did it.

Step 1 – Information Assortment
One of many hardest elements 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 difficult. We primarily used two datasets for this evaluation:
GitHub Exercise DataThis is offered 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 need to 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 comparable to github:username/reponame. Utilizing this regex, we had been in a position to extract the repository, file identify, and file contents for every file that incorporates 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 mission that goals to mixture all of the dependency from multi totally different packager managers right into a graph-like dataset. That is wonderful 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 accessible to obtain without cost. Uncompressed, this dataset is over 100GB+ however may be loaded straight right into a database for simpler processing.
It was vital that we use the 2 datasets as a result of every one is sweet at various things. The “Github Exercise Information” dataset allowed us to search out each attainable Github hyperlink referenced in a repository, even when it’s not being utilized in an apparent place like a bundle supervisor manifest. Among the most fascinating findings weren’t essentially direct code dependencies. We frequently discovered Github URLs used straight in a bash script to clone a repository or a docker picture that may 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 may 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 affect 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 bundle supervisor. Moreover, we wished to take away any hyperlinks that weren’t really getting used as a dependency. Many of those hyperlinks had been utilized in feedback, for instance, one thing like: //code impressed from, or in documentation textual content recordsdata. Since we had been primarily involved with the opportunity of code injection, we trimmed off something that was not going for use straight by the code. This left us with a little bit over 2 million distinctive GitHub hyperlinks that had been referenced by recordsdata in significant methods.
Step 3 – Hijackable Usernames
Now that we now have a clear(er) checklist of tasks that straight depend upon a GitHub hyperlink, we would have liked to search out which customers had been at present unregistered. At this level, we had about 650ok Github usernames that we needed to kind by means of. Utilizing the GitHub API we might examine to see if a username exists, however we had been fee restricted to five,000 requests an hour, which signifies that it will have taken us over 5 days to examine all of the usernames. With a little bit little bit of intelligent logic and the GitHub GraphQL API, we had been in a position to carry that right down to a little bit 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 truthfully weren’t anticipating the quantity to be so excessive. We thought that lower than 1% of the usernames we discovered had been going to be hijackable. Apparently, individuals get tired of their usernames excess of anticipated.
Step 4 – Weak 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 mission 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 straight susceptible to repository hijacking. These tasks have a mixed GitHub begin rely of over 500,000 stars and embrace tasks in nearly each language from a few of the greatest open supply organizations.
This quantity alone is terrifying, however fashionable codebases aren’t big monolith dwelling inside single repositories. As a substitute, they rely and depend upon many different tasks for performance. That is nice for maintainability and reusability, however it signifies that a vulnerability in a single well-liked dependency can enormously affect many tasks down the dependency chain. Successfully any mission that’s depending on one of many 18,000 straight susceptible tasks is itself additionally susceptible.
Step 5 to ∞ – Dependency Evaluation
Now that we had a listing of straight susceptible tasks, we used that together with our earlier dataset to carry out a dependency graph taint search and discover each mission that relies on a susceptible repo of their provide chain. For this evaluation, we included regular dependencies and fewer apparent ones comparable to improvement dependencies or dependencies which aren’t in the principle bundle manifest file. If one in every of these auxiliary dependencies is susceptible to repo sniping, it would take a little bit longer for the affect to propagate up the dependency chain since it would 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 checklist of susceptible tasks grows exponentially out of hand, we slowly walked the graph one depth layer at a time. Between every move, we manually went by means of the outcomes and trimmed off any apparent false positives to attenuate error propagation and guarantee our outcomes didn’t get full of 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 move, the explanation grew to become clear; we had reached a number of large frameworks which are foundational and relied on by hundreds of different tasks.
This was sufficiently deep for us to know the affect of this vulnerability. General, Safety Innovation discovered over 70,000 impacted tasks, with a grand whole mixed GitHub star rely of over 1.5 million; that’s extra stars than the mixed whole of the highest eight greatest GitHub repositories ever. It’s arduous to precisely measure, however we estimate that these tasks have a mixed whole of a minimum of 2 million day by day downloads.
Impacted tasks embrace repositories from large organizations comparable to Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and plenty of others. The whole lot from small private person tasks to well-liked internet frameworks utilized by a whole lot of hundreds of organizations is affected. It’s also fascinating to notice simply what number of various kinds of software program this impacts. We discovered susceptible router firmware, video games, crypto wallets, cellular apps, and plenty 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 personal mission’s provide chain.
Don’t Hyperlink On to GitHub Repositories
That is the obvious one: GitHub repositories aren’t, and have by no means claimed to be, an alternative to a bundle supervisor. There are not any ensures that GitHub hyperlinks are static, and so they shouldn’t be used as direct code dependencies. Utilizing a devoted bundle supervisor has many benefits, each from a usability and safety perspective, and may all the time be most well-liked over straight linking to a repository. Nonetheless, do be aware that you could be nonetheless be susceptible to repo jacking if one in every of your dependencies themselves straight hyperlinks to a GitHub URL even in the event you examine 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 typically with construct scripts, which fetch code straight from a developer’s repository, or inside testing code. Whether it is susceptible to a hidden repository hijacking, the subsequent time that dependency will get up to date, it might comprise malicious code that then makes its manner into your software.
Model Pinning and Lock Recordsdata
One other manner to assist mitigate this vulnerability is thru model pinning and lock recordsdata. Model pinning is when a selected 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 typically a SHA1 git commit hash, which is included to instruct your bundle supervisor device to solely obtain that particular commit of a git repository. The objective with that is that even when that repo will get hijacked, a malicious attacker wouldn’t be capable to modify the code with out additionally modifying the commit hash. You may also model pin a dependency to a selected department or tag, however there may be nothing to cease a malicious person 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 bundle supervisor device that features a checklist of version-pinned dependencies to make sure that subsequent time somebody tries to construct that mission, they obtain the very same bundle and model specified within the lock file. Lock recordsdata can even generally embrace an integrity hash of the downloaded bundle to additional guarantee its authenticity.
Model pinning and lock file implementations are bundle supervisor particular, however most massive packager managers help these options. That being mentioned, they’re removed from foolproof.   The truth is, whereas we had been conducting this analysis, we managed to bypass most main bundle 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 have got already downloaded the code you want. The caveat right here is that you simply would possibly nonetheless change into susceptible the subsequent time you replace your dependencies if a type of dependencies has been hijacked. Many builders simply replace all their dependencies when their bundle supervisor tells them to, with out wanting that the precise adjustments that had been made.   In these instances, vendoring gives little or no safety because it solely works in the event you preserve a detailed eye on dependency upgrades.
Hopefully, this text helped shed some mild on the impacts of dependency repository hijacking and permit tasks to higher safe their dependencies provide chains. The proliferation of COTS, third social gathering software program, and open supply will proceed to develop, and together with it, so will the variety of assaults concentrating on them. Though using third social gathering dependencies get options out the door faster and reduces improvement time, it’s crucial that you simply scrutinize them the identical manner you do your personal code – maybe much more so.