Skip to content

Security Widely confirmed7 publishers 2 min read Published Updated

Hijacked .gh, .sl and .as registries handed attackers HTTPS certificates for Google domains

Attackers who hijacked the operators of three country-code domains obtained HTTPS certificates for Google domains, Google disclosed. The company says the issuing CAs did nothing wrong, so its defence came after issuance, and it cannot promise it found every affected domain.

The Watch · Security desk

Send a correction

Illustration accompanying Hijacked .gh, .sl and .as registries handed attackers HTTPS certificates for Google domains
Generated illustration

What happened

  • The .gh, .sl and .as registries were run by third-party operators, and the attackers used that access to change authoritative DNS records for names under those endings.
  • Google blocked the certificates for its own properties in Chrome through CRLSets and worked with the issuing CAs to revoke them for other browsers and clients.
  • Certificate Transparency log data turned up other victims, including large global brands and popular online services, and Google blocked those certificates in Chrome too.
  • Google learned of the hijacks last week and has not said how the registries were breached, who carried it out, or when it began.

Why it matters

  • What it limits constraint Correct CA behaviour did not prevent issuance, so for these names the controls that counted sat with the registry operator and with monitoring after a certificate already existed.
  • Who has to decide decision Owners of names under .gh, .sl and .as are left to search CT logs themselves, since Google's blocks and revocations reach only the certificates it found.
  • What it sets up precedent Google closed its disclosure with a commitment to shorter certificate validity and less DCV reuse through its root programs, so CAs can expect tighter rules on both.

Google places the failure below the certificate authorities. "Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong," the company said [4]. The attackers held the authoritative DNS records for the names involved [2]. The CAs issued certificates because the attackers controlled those records, and Google says no CA made an error [13].

"These incidents did not involve a compromise of Google's systems," Google said [3]. The attackers got Google's certificates, and the other brands' certificates, by going through registry operators those companies do not run [16]. A registry takeover exposes every name under its ending [2]. An organisation with names under many country endings depends on every one of those registries for its domain-validated certificates. A breach at any one of them is enough to get certificates issued for the names under it [16].

Three registry operators were compromised in one set of incidents, and Google links the other victims it found to the same attacks [17]. On that evidence the attackers got in through the registry operators. Individual brands were not breached [17].

Chrome users are covered for the certificates Google found. "Chrome users do not need to take any action to be protected," Google wrote [7]. The company also said its Chrome interventions do not reliably protect people using other browsers [10]. Outside Chrome, the only remaining defence is CA revocation [14]. "We cannot guarantee that our analysis identified every affected domain," Google said [9]. If its analysis missed a domain, any certificate for that domain is neither blocked in Chrome nor revoked [14].

Google's longer-term answer is root-program policy. "To keep our users safe, we are committed to long-term HTTPS ecosystem improvements, such as reducing certificate validity and DCV reuse, through the Chrome Root Program and the new Chrome Quantum-resistant Root Program," the company said [11]. Both measures are about time limits: how long a certificate stays valid, and how long a CA can reuse an earlier domain control check [15]. Google said it would go on working with others to reduce the harm when DNS or routing is compromised [12].

What to watch

  • Disclosure from the .gh, .sl or .as operators on how they were breached and whether they have confirmed control of their DNS records.
  • New certificates for affected brands appearing in Certificate Transparency logs, or victims Google contacted confirming they were hit.
  • Chrome Root Program proposals that cut certificate validity or DCV reuse periods and cite these hijacks.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence70
Adoption
Not scored
Hype gap+15
Incentives40
Confidence68

Perspective Coverage

8 publishers
Builder
Builder 24%
Operator
Operator 69%
Investor
Investor 7%
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    Attackers who took control of three country-code top-level domains used that access to obtain HTTPS certificates for several Google domains and for domains run by other large organizations, Google disclosed on Tuesday.

    Reported SupportedView cited source
  2. [2]

    Attackers compromised the third-party operators of the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) ccTLDs, putting every domain under those endings at risk, and then changed the authoritative DNS records.

    Reported SupportedView cited source
  3. [3]

    "These incidents did not involve a compromise of Google's systems," the company said.

    Reported Supported Source: GoogleView cited source
  4. [4]

    "Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong," Google said.

    Reported Supported Source: GoogleView cited source
  5. [5]

    Google blocked the unauthorized certificates for its own properties in Chrome through CRLSets, a list Chrome downloads in the background to block revoked certificates, and worked with the issuing CAs to revoke those certificates so users of other browsers and clients are protected too.

    Reported SupportedView cited source
  6. [6]

    Certificate Transparency log data revealed other organizations believed to be hit by the same attacks, among them several large global brands and popular online services; these were blocked in Chrome as well, and Google contacted the affected organizations where it could.

    Reported SupportedView cited source
  7. [7]

    "Chrome users do not need to take any action to be protected," Google wrote.

    Reported Supported Source: GoogleView cited source
  8. [8]

    Google learned of the hijacks last week and did not say how the registries were compromised, who is behind the attacks, or when they began.

    Reported SupportedView cited source
  9. [9]

    Google warned that browser-side blocking should not be the only line of defense and said that, due to the complexity of DNS hijacks, "we cannot guarantee that our analysis identified every affected domain."

    Reported Supported Source: GoogleView cited source
  10. [10]

    Google noted that Chrome's interventions do not reliably protect people using other browsers.

    Reported Supported Source: GoogleView cited source
  11. [11]

    "To keep our users safe, we are committed to long-term HTTPS ecosystem improvements, such as reducing certificate validity and DCV reuse, through the Chrome Root Program and the new Chrome Quantum-resistant Root Program," the company concluded.

    Reported Supported Source: GoogleView cited source
  12. [12]

    Google plans to keep working with the wider community to limit the damage that DNS and routing compromises can cause.

    Reported SupportedView cited source
  13. [13]

    The certificates were issued on the strength of the attackers' control of the authoritative DNS records, with no CA error involved, according to Google's account.

    Derived Supported
  14. [14]

    Outside Chrome, protection rests on CA revocation, and certificates for any affected domain Google's analysis missed are neither blocked in Chrome nor revoked.

    Derived Supported
  15. [15]

    Both measures Google named act on time limits: how long a certificate stays valid and how long an earlier domain control check can be reused.

    Derived Supported
  16. [16]

    Google and the other affected organisations had certificates obtained for their names through third-party registry operators they do not run; an organisation's domain-validated certificates depend on every registry it holds names under, and a breach at one exposes the names there.

    Derived Supported
  17. [17]

    Three separate registry operators were compromised in one set of incidents, so the point of entry was the registry operators, not the individual brands.

    Derived Supported

Sources

7 independent publishers whose own reporting we read for this story.

  1. arstechnica.com

    1 article · October 6, 2026

    Hackers obtain counterfeit TLS certificates for Google and other large services
  2. bleepingcomputer.com

    1 article · October 7, 2026

    Hackers hijack Google domains after breaching ccTLD registries
  3. helpnetsecurity.com

    1 article · October 7, 2026

    Hackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains
  4. infosecurity-magazine.com

    1 article · October 8, 2026

    Attackers Hijack Three ccTLDs to Obtain Google Certificates
  5. malwarebytes.com

    1 article · October 8, 2026

    Attackers hijack country-code domains to impersonate Google and other services
  6. scworld.com

    1 article · October 7, 2026

    Attackers hijack top-level domains to mint counterfeit TLS certificates
  7. securityweek.com

    1 article · October 9, 2026

    Google Domains Impacted by Recent ccTLD Hijacks
  8. thehackernews.com

    2 articles · October 8, 2026

    Attackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains

Topics and entities

Topics

  • Country-code top-level domains
  • Web PKI
  • Certificate Transparency

Entities