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
    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.