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 brought on us to analyze the prevalence of dependency repository hijacking which is an obscure vulnerability that enables anybody to hijack a repository if its proprietor modifications their username. This vulnerability is just like subdomain takeover, trivial to take advantage of, and leads to distant code injection. After analyzing open-source tasks for this difficulty and recursively looking out by means of their dependency graphs, we discovered over 70,000 impacted open-source tasks; this consists of widespread tasks and frameworks from firms like Google, GitHub, Fb, and lots of others. To mitigate this difficulty, make sure 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 every little thing from net frameworks to cryptocurrencies. This vulnerability is trivial to take advantage of, leads to distant code injection, and impacts main tasks from firms like Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and lots of others. After first discovering it in a latest engagement, we needed 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 almost certainly impacts you not directly.
Who’s susceptible?
Each mission whose compilation will depend 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 instantly reference a GitHub repository (normally as a dependency).
The proprietor of that repository must then change/delete their username.
When the linked repository proprietor modifications their username, it turns into instantly out there to be re-registered by anybody. Because of this any mission that linked again to the unique repository URL has now develop 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 will depend on it.
Must you be involved?
Even when your mission that has a dependency on a GitHub isn’t susceptible proper now, if the proprietor of considered one of its dependencies modifications their username, that mission and all different tasks that depend upon the previous hyperlink develop into susceptible to repo jacking. You’ll anticipate there to be some sort of warning when repository modifications areas, possibly a “404 – Repository not discovered” sort 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 person modifications both the title 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 modifications 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 truly 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 trusted would now begin loading code from this new repository.
Redirection is a handy characteristic because it means your hyperlinks don’t instantly break while you rename your account. However it additionally signifies that your mission can unknowingly develop into susceptible to repo jacking. Out of your perspective, nothing has modified – your code nonetheless compiles the identical, and every little thing works because it ought to. Nonetheless, your mission is now susceptible to distant code injection, and you might be none the wiser.
The three Hijack Situations
To get slightly extra particular, there are technically three alternative ways a repository can develop into hijackable:
A GitHub person renames their account. That is the most typical manner a repository turns into hijackable since it’s not unusual for a person to rename their account and after they do, every little thing continues working as anticipated as a consequence of 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 would begin having errors when attempting to fetch the repo.
Notice: There have been a number of circumstances (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, they usually knowledgeable us that this can be a identified difficulty however that they at the moment would not have any plans to alter the way in which redirection or username reuse works. They’ve offered some mitigations to this drawback for some widespread 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 just isn’t a foolproof resolution as many smaller repositories don’t meet this criterion however will be nonetheless be depended upon by widespread tasks. As such, builders that needed to make use of them wanted to hyperlink on to GitHub.
The foundation drawback right here just 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 package deal managers out there (the truth is, GitHub themselves has one) constructed to unravel the issue of distant code dependencies, and builders have the duty 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 just 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 tough. 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; the complete dataset is over 3TB price of content material. Conveniently, it’s hosted as a public BigQuery dataset on the Google Cloud Platform (GCP), which signifies that we are able to use BigQuery to run SQL instructions over the complete dataset from inside GCP itself, and we don’t need to obtain the complete 3TB+ file.To truly carry out the search, we generated a regex that catches any Github URL or different widespread Github dependency hyperlink codecs comparable to github:username/reponame. Utilizing this regex, we have been in a position to extract the repository, file title, 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 completely different Github customers. is an open-source mission that goals to mixture all of the dependency from multi completely 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 the complete dataset out there to obtain at no cost. Uncompressed, this dataset is over 100GB+ however will be loaded instantly right into a database for simpler processing.
It was vital that we use the 2 datasets as a result of every one is nice at various things. The “Github Exercise Information” dataset allowed us to search out each potential Github hyperlink referenced in a repository, even when it’s not 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 frequently discovered Github URLs used instantly in a bash script to clone a repository or a docker picture that might pull a repository from Github when constructed.
Instance set up script; the GitHub hyperlinks can be found to be registered by anybody.
One other widespread discovering was hijackable repositories as Git submodules, one thing that might have been missed by normal 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 impression of this vulnerability to open supply tasks.
Step 2 – Clear Up
Now that we had collected all this information, we wanted to sanitize and normalize it. This was a sizeable effort since we wanted to account for the completely different codecs of every package deal supervisor. Moreover, we needed to take away any hyperlinks that weren’t truly 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 slightly over 2 million distinctive GitHub hyperlinks that have been referenced by recordsdata in significant methods.
Step 3 – Hijackable Usernames
Now that we’ve a clear(er) listing of tasks that instantly depend upon a GitHub hyperlink, we wanted to search out which customers have been at the moment unregistered. At this level, we had about 650okay Github usernames that we needed to kind by means of. Utilizing the GitHub API we might test to see if a username exists, however we have been price restricted to five,000 requests an hour, which signifies that it might have taken us over 5 days to test all of the usernames. With slightly little bit of intelligent logic and the GitHub GraphQL API, we have been in a position to convey that all the way down to slightly over 2 hours to scan all 650okay customers.
So, what are the outcomes? We discovered that about 7% (about 50okay) 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 have been going to be hijackable. Apparently, folks get tired of their usernames way over 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 kind 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 rely of over 500,000 stars and embrace tasks in just about each language from a number of the largest open supply organizations.
This quantity alone is terrifying, however trendy 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, but it surely signifies that a vulnerability in a single widespread dependency can drastically impression many tasks down the dependency chain. Successfully any mission 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 mission that will depend on a susceptible repo of their provide chain. For this evaluation, we included regular dependencies and fewer apparent ones comparable to growth dependencies or dependencies which aren’t in the principle package deal manifest file. If considered one of these auxiliary dependencies is susceptible to repo sniping, it’d take slightly longer for the impression 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 cross, we manually went by means of the outcomes and trimmed off any apparent false positives to reduce 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 cross, the explanation grew to become clear; we had reached a number of big frameworks which might be foundational and trusted by 1000’s of different tasks.
This was sufficiently deep for us to know the impression of this vulnerability. Total, Safety Innovation discovered over 70,000 impacted tasks, with a grand complete mixed GitHub star rely 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 a minimum of 2 million each day downloads.
Impacted tasks embrace repositories from big organizations comparable to Google, GitHub, Fb, Kubernetes, NodeJS, Amazon, and lots of others. The whole lot from small private person tasks to widespread net frameworks utilized by a whole lot of 1000’s of organizations is affected. It is usually 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, you will need to 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 choice 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 at all times be most popular over instantly linking to a repository. Nonetheless, do word that you could be nonetheless be susceptible to repo jacking if considered one of your dependencies themselves instantly hyperlinks to a GitHub URL even should you test every of your transitive dependencies for direct hyperlinks, a kind of dependencies may 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 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 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 objective with that is that even when that repo will get hijacked, a malicious attacker wouldn’t be capable of modify the code with out additionally modifying the commit hash. It’s also possible to model pin a dependency to a selected department or tag, however there’s 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 package deal supervisor software that features a listing of version-pinned dependencies to make sure that subsequent time somebody tries to construct that mission, they obtain the very same package deal and model specified within the lock file. Lock recordsdata can even generally embrace 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 massive packager managers assist these options. That being mentioned, 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 submit 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 shield you in opposition to repo jacking. Since all of your dependencies are already downloaded, it is sort of a lock file that additionally consists of the content material on your dependencies. Even when a kind of dependencies will get hijacked, you might have already downloaded the code you want. The caveat right here is that you just may nonetheless develop into susceptible the subsequent time you replace your dependencies if a kind 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 modifications that have been made.   In these circumstances, vendoring supplies little or no safety because it solely works should you hold 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 occasion software program, and open supply will proceed to develop, and together with it, so will the variety of assaults focusing on them. Though the usage of third occasion dependencies get options out the door faster and reduces growth time, it’s vital that you just scrutinize them the identical manner you do your personal code – maybe much more so.