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

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.
Next story · Security · 2d ago
XBOW built a Windows Chrome exploit chain in six days with about $40,000 of AI computeConfirmed4 publishers
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%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [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.
- [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.
- [3]
"These incidents did not involve a compromise of Google's systems," the company said.
- [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.
- [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.
- [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.
- [7]
"Chrome users do not need to take any action to be protected," Google wrote.
- [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.
- [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."
- [10]
Google noted that Chrome's interventions do not reliably protect people using other browsers.
- [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.
- [12]
Google plans to keep working with the wider community to limit the damage that DNS and routing compromises can cause.
- [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.
- [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.
- [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.
- [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.
- [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.
Sources
7 independent publishers whose own reporting we read for this story.
- arstechnica.comHackers obtain counterfeit TLS certificates for Google and other large services
1 article · October 6, 2026
- bleepingcomputer.comHackers hijack Google domains after breaching ccTLD registries
1 article · October 7, 2026
- helpnetsecurity.comHackers hijack three country-code domain registries, obtain HTTPS certificates for Google domains
1 article · October 7, 2026
- infosecurity-magazine.comAttackers Hijack Three ccTLDs to Obtain Google Certificates
1 article · October 8, 2026
- malwarebytes.comAttackers hijack country-code domains to impersonate Google and other services
1 article · October 8, 2026
- scworld.comAttackers hijack top-level domains to mint counterfeit TLS certificates
1 article · October 7, 2026
- securityweek.comGoogle Domains Impacted by Recent ccTLD Hijacks
1 article · October 9, 2026
- thehackernews.comAttackers Hijack .gh, .sl, and .as Registries to Obtain Certificates for Google Domains
2 articles · October 8, 2026
Topics and entities
Topics
- Country-code top-level domains
- Web PKI
- Certificate Transparency
Entities
- Let's Encrypt
- Google Chrome
- Google Trust Services
- Matthew McPherrin
- CA/Browser Forum
- Chrome Root Program