This came up recently in a different HN thread: https://news.ycombinator.com/item?id=19118740

The main gist is that GitHub doesn't require proof of ownership in order to set a custom domain.

This means that if your GitHub Pages configurations are incorrect for any reason (for example, that user switched from a Pro to a regular account and lost the ability to have a GH page on a private repo), another user can come along and claim your page (confidencetoexplore.com) as the custom domain for that repo.

My bet would be that this happened to you. As another user in that thread mentioned, report them: https://github.com/contact/report-abuse

Son of a biscuit! This is exactly what happened. They said I could have my 7 private repos without a Pro account so I downgraded and didn't realize it shut down my gh-pages websites. Then this schmuck comes along and steals them. THANK YOU TO EVERYONE WHO IS REPORTING THIS!!

Thank you for "son of a biscuit"! Best pseudo-swear since "Shut the front door".

In french my wife uses "lutin en herbe" (or just "lutin") instead of "putain de merde"

Google translate says "budding goblin" ... I'm just going to use that in English

Yes. This is what I just discovered. OP here's the malicious github account, so we can get it banned:

https://github.com/OnyonCapitaly

I found a repo with your domain:

https://github.com/OnyonCapitaly/confidencetoexplore.com

edit: just reported them, but you should too OP.

Aaaand it’s down! Good job Github and everyone who helped.

Hope this helped, OP

The script kiddie will just signup for another account and "hack" the same sites again.

At least now they have to go through that effort again

Does GitLab have this issue? Don't they offer all this for free, unlike GitHub?

I don't know if they handle this case better specifically, but I found almost all GitLab page functionality is better than GitHub - plus it's more generic, you can wire any static page generator into the built-in CI/CD, not just limited to jekyll or doing it yourself.

GitLab requires you to put a txt record with a verification code in your custom private domain DNS to verify ownership.

TL;DR no, GitLab does not have that issue.

Confirming the previous poster's comment on GitLab Pages domain ownership verification functionality, which was rolled out in February of 2018. https://about.gitlab.com/2018/02/05/gitlab-pages-custom-doma...

Thank you! This is nuts that this can happen and someone would do such a thing. Stupid.

You are awesome. Good work!

Thanks! This is the first time I've done this kind of internet sleuthing. It's a fun experience.

Reported too...

Thank you!

GitHub recebtly introduced a domain verification system for an unrelated feature, they should really integrate it with Pages.

That thread was 54 days ago, and the flaw was being exploited and was reported to GH then.

Shouldn't they, I don't know, do something beyond banning accounts caught exploiting this?

That thread is 2months old and GitHub/Microsoft still hasn't closed this security hole.

They should at least flag accounts with an unusually high number of custom domains. Seems easy to do IMO.

Yes, I got my GitHub page 'hijacked' in a similar way some time ago when I switched the repo to private (when GitHub announced free private repos for regular account).

Quick response from GitHub after raising a report and got my CNAME back after going through the domain ownership verification with them.

UPDATE: Github responded with the following...

(GitHub Developer Support)

Apr 4, 2:52 AM UTC

Hi Scott,

Thanks for reaching out, and sorry for the trouble!

GitHub Pages doesn't currently have a verification process when configuring a new custom domain. We chose this design due to its low friction, but unfortunately it also means that any GitHub user can claim any custom domain, so long as it isn't already in use on another repository.

When you downgraded your account to GitHub Free, GitHub Pages for your private repository was disabled, and this released your custom domain for potential use by other GitHub users. While the risk of another user accidentally claiming your specific custom domain is low, we've experienced trouble lately with opportunistic ne'er-do-wells strategically claiming custom domains they find to be available.

Our engineering team is currently investigating potential improvements to prevent this in future. In the meantime, we're taking the precaution of performing manual verification in any cases such as yours. A quick way we can verify your ownership of the domain would be for you to add a TXT record to your domain's DNS configuration.

When you create the TXT record, please include the following value:...

and from there gave me a value to put in my DNS to verify ownership.

Not a great experience today but at least they responded and are working to remedy the situation (which I still believe was a huge ball drop on their part in terms of both communication and implementation).

I had this exact same problem too on March 26th and my first response was poor, the rep said "I'm sorry to hear that your domain was taking [sic] over by another user" and tried to get me to verify my own domain with them. I told them that I was disappointed with the response and then another support rep wrote a much more helpful and detailed reply:

"Sorry for the trouble you've had with this.

GitHub Pages doesn't currently have a way of linking ownership of a domain to a GitHub account. When you point your domain's DNS records towards GitHub IPs all we can tell on our side is that the domain can be attached to a Pages site—but we can't tell which one, or which account it's owned by, until the domain is linked in the repository settings page.

When you leave your domain pointing towards GitHub, but don't attach it to a live Pages site, any other GitHub user can link your domain to a Pages site without any further verification. All we can see from your domain are the GitHub IPs listed in the DNS records, so we have no way of linking it to a specific account.

As this domain is now attached to a Pages site, we have to consider that the person currently using it is the legitimate owner, whether that be via a domain ownership transfer, the domain has expired and someone else has purchased it, or other means.

We use this setup to make it quick and easy to get started with GitHub Pages, without having to perform even more complex DNS verification steps or waiting for propagation time. We are aware that it can be abused however and are looking at possible solutions, but we don't have anything to announce at this time.

If you would like to use this domain with GitHub Pages again yourself then you will need to follow the verification process. If you don't want to use this domain with GitHub Pages then you can safely remove any DNS records that point towards GitHub to stop the malicious site displaying at your domain. However you may have to verify it with us again in future if you would like to use GitHub Pages again.

Let us know if you have any further questions, or would like to continue verifying your ownership of your domain with us."

It's great to hear that at least they have some mitigation for this issue so it never happens again. It's nice that you brought awareness to this issue so a process change could be made at GH HQ.

The same happened to me, I searched my CNAME on github and found that a user was "hijacking" some CNAMEs, pointing these domains to his own repos. This happened to me because I switched from PRO to Free and I didn't notice that the Free plan does not allow us to have a private repository with Github Pages. The end result in my case is that I migrated my blog to Netlify and used Hugo to generate my HTML site from Markdown files. It was very straightforward and I am satisfied with the end result.

That’s exactly how I found the CNAME takeover in the case of OP. I guess if this happens to anyone, the first mitigation step would be to search all of GitHub for that CNAME.

Migrating to GitLab would solve this issue.

This reminds me of the awful Cloudfront vulnerability where any jerk can park your domain names in Cloudfront with no verification. One day you'll put one of your domains behind Cloudfront and suddenly they own your website.

Scenario:

1. Today your DNS records look like this because you aren't using Cloudfront:

  site.com -- A --> 1.2.3.4
  www.site.com -- CNAME --> site.com

2. Some jerk with an AWS account registers "www.site.com" in Cloudfront.

3. Tomorrow you create a cloudfront distribution for site.com and change site.com to a CNAME to "d12345abcdef.cloudfront.net". Instantly you're owned on WWW.site.com because it indirectly points to Cloudfront and you forgot to register that alias in AWS. Oh and guess what? The jerk can issue SSL certs for your domain name through Lets Encrypt because all they need to do is put a well-known file off your domain.

4. You have a bug bounty program (right?!) and pay quick, big money out to some researcher who is, thankfully, not a jerk.

Good times.

The real problem here is that they do not notify people that on the Free plan, you can have Pages on a public repo, or a private repo without Pages. But you can’t have Pages on a private repo.

With GitLab you can have a private repo for your Pages.

That's nice.

I haven’t knew that Pro account is required to host static content for private repos. It’s better move to gitlab because my student pro account going to end soon.

I am not an expert, but did you checked your domain authoritative DNS servers?

I've logged into my DNS provider and confirmed everything is set up the same as my other github pages which are working fine. Is that what you're asking?

I checked your's and it is the same as for Aditya, so it might be OK. Weird stuff, I do not understand how it is possible.

host -t ns confidencetoexplore.com confidencetoexplore.com name server dns1.registrar-servers.com. confidencetoexplore.com name server dns2.registrar-servers.com.

It's a malicious takeover of a domain due to a process oversight from GH. They should check if a person actually controls the domain before letting any GH user host a GH pages site on that domain.