ccTLD registry hijack: how attackers got Google certificates

Attackers broke into the companies that run three country-code domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), and used that access to get real, browser-trusted HTTPS certificates for several Google domains and for other big brands. Google disclosed the ccTLD registry hijack on October 6, 2026, in a post from its Chrome security team, and says Chrome already blocks the certificates. The bigger question is everyone else: people on other browsers, and anyone who owns a domain.

Key takeaways

• The breach was at the registry, not at Google: Google says attackers compromised the third-party operators of .gh, .sl and .as, which put every domain ending in those suffixes at risk. Google's own systems were not breached.
• The certificates were technically valid: by changing authoritative DNS records, the attackers could pass the domain checks certificate authorities (CAs) run. Google says it has no reason to think the CAs did anything wrong.
• Chrome users are covered; others may not be: Chrome blocks the certificates through its CRLSets list, and the CAs revoked them, but Google warns its fixes do not reliably protect non-Chrome users.
• Domain owners have two jobs: watch Certificate Transparency logs for every domain you own, and publish restrictive CAA records that name your CA and account.

What happened in the ccTLD registry hijack

Every domain ending in a country code sits under a registry that holds its authoritative DNS records, the answers the rest of the internet trusts about where a domain points. Google says it learned "last week" of hijacks in the .gh, .sl and .as namespaces, in which attackers modified those records. It has not said how the registries were compromised or who is behind it.

Controlling DNS is enough to get a certificate. Most CAs issue a domain-validated certificate to whoever can prove control of a domain, usually by answering a DNS or web challenge. With the records rewritten, the attackers could pass that check and obtain Google certificates for names under those suffixes. A Let's Encrypt staff member confirmed on the CA's community forum on October 7 that "certificates for Google and Youtube were issued, and have been revoked."

Google did not publish a count. iTnews reports, from public Certificate Transparency data, that the .gh registry was compromised on September 22, .sl on September 25 and .as on September 27 (UTC), and that it found 32 certificates issued to the attackers between September 22 and 27. iTnews says it contacted the three registry operators and got no reply.

Who is still exposed

Google says it blocked the certificates for its own properties in Chrome via CRLSets, a list of revoked certificates Chrome pushes to browsers, and worked with the issuing CAs to revoke them. Certificate Transparency data then turned up "several leading global brands and widely used online services" hit by the same attacks, and Chrome blocked those certificates too. Google did not name them.

Google is blunt about the limits: it "cannot guarantee" it found every affected domain, and Chrome's interventions do not reliably protect people on other browsers. Firefox checks revocation with CRLite, which Mozilla says covers all revocations logged in Certificate Transparency and refreshes every 12 hours on desktop. As of October 9, 2026, we found no public statement from Mozilla, Apple or Microsoft on this incident. Our reading: revocation is what protects users outside Chrome, so apps and devices that skip revocation checks are the likeliest gap.

What domain owners should do now

Google's advice is aimed at anyone who owns domains, not only those under .gh, .sl or .as.

1. Monitor Certificate Transparency for every domain you own. Chrome requires trusted certificates to be published in public CT logs, so a monitor alerts you when one appears for your name. Include parked and regional country-code domains. The CT project keeps a list of monitoring services, and if you own a .gh, .sl or .as domain, Google says to review recent entries now.
2. Publish restrictive CAA records. A CAA record tells CAs which of them may issue for your domain. RFC 8657 adds the account and the validation method, for example example.com. CAA 0 issue "letsencrypt.org; accounturi=<your ACME account URL>; validationmethods=dns-01".
3. Know what CAA can't do. Google notes CAA cannot stop issuance during an active DNS hijack, since the attacker controls the records. It matters afterward: CAs may reuse a completed domain check, and a tight CAA policy stops an attacker from using that cached check to get new certificates once you regain control.

Google also points to longer-term fixes: shorter certificate lifetimes and less reuse of domain checks, already scheduled by the CA/Browser Forum's ballot SC-081v3.

For more on attacks that hit the infrastructure organizations trust, see our FortiGate admin lockout story and the ASOS data breach.

Bottom line

The ccTLD registry hijack shows that whoever controls a domain's DNS can get a valid certificate for it, even for Google. If you use Chrome, Google says you need to do nothing. If you use another browser, the CA revocations are your protection, and no other browser maker had commented as of October 9, 2026. If you own domains, set up CT monitoring and restrictive CAA records today. Watch for the registries to explain how they were breached. More in our software section.

FAQ

What is a ccTLD registry hijack?

A ccTLD is a country-code top-level domain, like .gh for Ghana. In a registry hijack, attackers take control of the operator that runs that suffix and change its DNS records, which lets them redirect domains under it and pass the checks CAs use to issue certificates.

Do Chrome users need to do anything?

No. Google says Chrome blocks the unauthorized certificates through CRLSets and that "Chrome users do not need to take any action to be protected."

Does a CAA record stop this attack?

Not while it is happening, Google says, because the attacker controls DNS. A restrictive CAA record that names your CA account and validation method helps once you regain control, by blocking new certificates based on cached domain checks.