On October 6, 2026, Google reported a major cybersecurity incident: unknown attackers hijacked the country-code top-level domain (ccTLD) registries of three countries — .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). According to the Google Security Blog, the attackers compromised the third-party operators managing the zones, putting all domains under those extensions at risk.
During the attack, the attackers altered authoritative DNS records to obtain unauthorized HTTPS certificates for several Google domains and domains belonging to other organizations. Google said the incident was not connected to any compromise of its own systems and emphasized that the certificate authorities (CAs) that issued the certificates had committed no violation.
How the Attack Was Carried Out
The attackers did not target Google's infrastructure directly — their targets were the domain-zone registries. Once the registry operators were compromised, they gained the ability to alter authoritative DNS records. After changing the DNS records, the attackers passed the automated domain-ownership validation checks and obtained TLS certificates from trusted certificate authorities that looked entirely legitimate.
Once armed with such a certificate, an attacker could intercept the traffic of users visiting the corresponding domain or run phishing attacks through lookalike sites displaying the trusted padlock icon. According to Ars Technica, it is precisely the registry-level control that made the attack especially dangerous: a browser cannot distinguish such a certificate from an ordinary legitimate one, because it was issued by a trusted authority and logged in public certificate logs. The incident was uncovered exactly through analysis of public logs — since every certificate issued by a certificate authority must be published, unexpected entries caught analysts' attention.
How Google Responded
Google acted immediately under its standard incident-response procedures. The company blocked the unauthorized certificates issued for Google resources in the Chrome browser via the CRLSets mechanism and, together with the authorities that issued them, took steps to revoke them — protecting users of clients other than Chrome as well.
After the initial protective measures were taken, analysis of Certificate Transparency (CT) logs identified additional organizations that may have been affected by these attacks. They included several leading global brands and widely used online services. Google preemptively blocked those certificates in Chrome and contacted the affected organizations where possible, alerting them to the detected cases and the measures taken.
The company openly stated that it cannot guarantee its analysis identified every affected domain:
"We cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users." — Google Security Blog
It was also noted that Chrome's measures do not reliably protect users of other browsers. At the same time, Google said Chrome users do not need to take any additional action to stay protected.
Google's Recommendations for Domain Owners
Google recommended several practical measures for domain owners to protect themselves and their users. The first recommendation is to continuously monitor Certificate Transparency logs for all domains. Because every certificate trusted by Chrome must be published in public CT logs, log monitoring gives a near-real-time signal when an unexpected certificate is issued for a domain. Organizations using domains in the .gh, .sl, or .as zones were advised to review recent CT entries — the monitoring should cover the entire domain portfolio, including parked or regional ccTLD holdings.
The second recommendation is to publish restrictive CAA records with ACME account binding. CAA DNS records allow domain owners to declare which certificate authorities are permitted to issue certificates for their domains. Although CAA cannot stop certificate issuance during an active DNS hijack, it serves an important protective function once DNS control is restored: because authorities are allowed to reuse previously completed domain control validation (DCV) checks for subsequent issuance, restoring a restrictive CAA policy blocks the attacker from using the cached validation state to issue new certificates. It was also noted that restricting issuance to specifically authorized accounts and validation methods can entirely prevent some routing- and HTTP-based attacks.
Google also said it would continue long-term work to improve the HTTPS ecosystem — including shortening certificate lifetimes and limiting DCV reuse. This work is carried out under the Chrome Root Program and the new Chrome Quantum-resistant Root Program.
