New GitHub Pages domain:

Beginning today, all GitHub Pages sites are moving to a new, dedicated domain: This is a security measure aimed at removing potential vectors for cross domain attacks targeting the main session as well as vectors for phishing attacks relying on the presence of the “” domain to build a false sense of trust in malicious websites.

If you’ve configured a custom domain for your Pages site (“” instead of “”) then you are not affected by this change and may stop reading now.

If your Pages site was previously served from a domain, all traffic will be redirected to the new location indefinitely, so you won’t have to change any links. For example, now redirects to

From this point on, any website hosted under the domain may be assumed to be an official GitHub product or service.

Please contact support if you experience any issues due to these changes. We’ve taken measures to prevent any serious breakage but this is a major change and could have unexpected consequences. Do not hesitate to contact support for assistance.

Technical details

Changes to Pages sites and custom domains:

  • All User, Organization, and Project Pages not configured with a custom domain are now hosted on instead of For instance, is now served canonically from
  • An HTTP 301 Moved Permanently redirect has been added for all** sites to their new ** locations.
  • Pages sites configured with a custom domain are not affected.
  • The Pages IP address has not changed. Existing A records pointing to the Pages IP are not affected.

Changes to GitHub repositories:

  • User Pages repositories may now be named using the new username/ convention or the older username/ convention.
  • Existing User Pages repositories named like username/ do not need to be renamed and will continue to be published indefinitely.
  • If both a and a repository exists, the version wins.

Security vulnerability

There are two broad categories of potential security vulnerabilities that led to this change.

  1. Session fixation and CSRF vulnerabilities resulting from a browser security issue sometimes referred to as “Related Domain Cookies”. Because Pages sites may include custom JavaScript and were hosted on subdomains, it was possible to write (but not read) domain cookies in way that could allow an attacker to deny access to and/or fixate a user’s CSRF token.
  2. Phishing attacks relying on the presence of the “” domain to create a false sense of trust in malicious websites. For instance, an attacker could set up a Pages site at “” and ask that users input password, billing, or other sensitive information.

We have no evidence of an account being compromised due to either type of vulnerability and have mitigated all known attack vectors.

Have feedback on this post? Let @github know on Twitter.
Need help or found a bug? Contact us.



Discover new ways to build better

Try Marketplace apps free for 14 days

Learn more