The GitHub Pages Loophole: How a DNS Misconfiguration Led to a Subdomain Hijack
Table of Contents
The Unexpected Alert
It is a nightmare scenario for any developer or site owner: returning from a trip to find your digital identity has been compromised. For one developer, a vacation through Africa with limited internet connectivity ended with a jarring notification from Google Search Console. The alert was specific and alarming: a new owner had been registered for a subdomain, kafka.immersivepoints.com.
The problem was that the owner had never created a ‘kafka’ subdomain. Their domain, immersivepoints.com, was designed for a single purpose—hosting a 3D and VR point cloud visualizer via GitHub Pages. There was no Kafka integration, no second developer, and certainly no authorization for a third party to spin up a site under their brand.
The Anatomy of a Subdomain Takeover
The breach wasn’t the result of a password leak or a sophisticated phishing attack. Instead, it was a classic case of a subdomain takeover, facilitated by a common DNS misconfiguration. The developer had configured their DNS records to point their domain to GitHub’s servers using a wildcard record. While this is a convenient way to ensure that www.immersivepoints.com and other potential subpages resolve correctly, it created a critical security vacuum.
GitHub Pages allows users to host static websites by adding a CNAME file to their repository. The system is designed for ease of use: if a domain’s DNS points to GitHub, and a GitHub user creates a repository with a CNAME file matching that domain, GitHub will serve the content from that repository.
The vulnerability lies in the trust mechanism. Because the developer’s DNS was wide open to GitHub’s IP range, any GitHub user could simply create a private repository, add a CNAME file for kafka.immersivepoints.com, and effectively ‘claim’ that piece of the domain. Because the repository was private, the original owner couldn’t even find the source of the hijack to flag it for abuse.
The Scam Ecosystem
This isn’t an isolated incident. Subdomain takeovers are a known tactic in the cybersecurity world, often used to bypass security filters and lend a veneer of legitimacy to malicious sites. In this specific instance, the hijacked subdomain was used to host “slot machine” scam sites—predatory pages designed to trick users into depositing money into fraudulent gambling platforms.
The invisibility of these attacks is what makes them dangerous. Many users would never notice the hijacking unless they had proactive monitoring in place. In this case, the Google Search Console alerts served as the only tripwire. Without them, the scam sites could have operated indefinitely, leveraging the reputation of the primary domain to deceive visitors.
Closing the Gap
The incident highlights a significant gap in how GitHub handles domain ownership. While the platform provides a domain verification feature—located within the account settings rather than the repository settings—it is not mandatory, nor is it prominently advertised during the setup process.
Currently, GitHub allows a repository to claim a domain as long as the DNS points to their servers. Security experts argue that a more robust verification process is needed, such as requiring a specific TXT record for every user authorized to host on a high-level domain. This would prevent random users from claiming subdomains simply because a wildcard DNS record exists.
For those using GitHub Pages, the solution is clear: avoid overly broad wildcard DNS records and utilize GitHub’s domain verification tools to ensure that only authorized accounts can associate their repositories with your custom domain.
