Gitjacking: From an Abandoned Repository to Website Compromise
Repository-related risks are not limited to exposed credentials or source code. References to repositories and GitHub identities can also become vulnerable when projects, accounts, or integrations are renamed, transferred, or abandoned.
This can create an opportunity for an attack known as gitjacking. In a gitjacking scenario, an attacker claims a repository name, account name, or hosting configuration that an organisation still trusts or references. The attacker can then publish content from a resource that appears to remain connected to the legitimate organisation.
During one engagement, River Security identified a gitjacking vulnerability affecting the public-facing website of a prominent customer. A repository-related resource used by the website was no longer controlled by the customer, but the website continued to trust or reference it.
By reclaiming the abandoned resource, our penetration testers were able to control content delivered through the customer’s website. This demonstrated that an attacker could have modified the public-facing site and potentially used the trusted customer domain to distribute misleading or malicious content.
The potential impact extended beyond visible website defacement. Depending on how the affected resource was used, an attacker could potentially have:
- Injected attacker-controlled content
- Redirected visitors to malicious websites
- Presented fraudulent login forms
- Distributed malicious downloads
- Damaged the customer’s reputation
- Abused the trusted domain in phishing campaigns
- Modified client-side code executed in visitors’ browsers
The vulnerability existed because the technical reference remained active after ownership of the underlying resource had been lost. From the website’s perspective, the resource was still trusted. From the hosting platform’s perspective, however, it was available for someone else to claim.
River Security responsibly demonstrated the impact, notified the customer, and provided the information required to remove the vulnerable reference and restore control of the affected resource.
This case highlights why repository security requires more than scanning source code for secrets. Organisations must also understand where repositories are referenced, who controls them, and what happens when projects or accounts are renamed, transferred, or deleted.
Repository decommissioning should therefore include:
- Identifying websites, applications, and pipelines that reference the repository
- Removing or updating associated DNS records
- Reviewing GitHub Pages and other static-hosting configurations
- Verifying ownership of custom domains
- Checking package managers, build systems, and deployment workflows
- Retaining control of organisation and repository names where appropriate
- Monitoring previously used resources for unexpected changes
An abandoned repository may appear harmless. When production systems continue to trust it, however, it can become a direct path to compromise.
Curious about how River Security monitors repositories and more? Read more here https://riversecurity.eu/code-repositories-a-wealth-of-information-and-potential-threats-how-river-security-protects-your-assets/
