Key facts
- Attackers compromised third-party operators of the country-code registries for Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as), putting every domain under those suffixes at risk.
- Google did not say how the registry operators were compromised, who is responsible, when the attacks began, or how many certificates were issued.
- CAA records cannot stop issuance during an active hijack. Restoring a restrictive CAA policy afterward prevents attackers from reusing cached domain control validation results to obtain new certificates.
- Google says it will pursue longer-term HTTPS ecosystem changes such as shorter certificate validity and less DCV reuse, through the Chrome Root Program and the new Chrome Quantum-resistant Root Program.
Attackers compromised third-party operators of the country-code top-level domain (ccTLD) registries for Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as), putting every domain under those suffixes at risk, according to Google’s Chrome Secure Web and Networking Team as reported by BleepingComputer and Infosecurity Magazine. A ccTLD is the two-letter ending assigned to a country or territory.
Google says the attackers modified authoritative DNS records, the records that tell the internet which servers answer for a domain, according to reports by BleepingComputer and SecurityWeek. They then used that control to get unauthorized HTTPS certificates covering several Google domains and domains of other organizations. Google dates its post Oct. 6, 2026, and says it learned of the hijacks the week before, per Infosecurity Magazine and Help Net Security.
What Google says happened
Google says its own systems were not breached in these incidents, and that it has no reason to believe the certificate authorities (CAs) that issued the certificates acted improperly. BleepingComputer and Malwarebytes explain why DNS control is enough: CAs typically verify domain ownership by checking a DNS record, so whoever controls a domain’s DNS can pass validation.
Google says it blocked the unauthorized certificates for its properties in Chrome through CRLSets, a list of revoked certificates that the browser receives from Google. It also says it worked with the issuing CAs to revoke them, which extends protection to other clients.
Google says Certificate Transparency (CT) logs, the public record of issued certificates, exposed further affected organizations, including large international brands and popular online services. It says it blocked those certificates in Chrome and notified the organizations where possible.
Google also acknowledges limits. It says it cannot guarantee it identified every affected domain, and that Chrome’s interventions do not reliably protect users of other browsers.
No actor named
Google did not say how the registry operators were compromised, who is responsible, when the attacks began, or how many certificates were issued, according to BleepingComputer, Infosecurity Magazine and iTnews. No group has been named, so there is no attribution, no confidence level and no set of aliases or infrastructure overlaps to compare.
iTnews, in its own comparison of CT logs against the Chrome blocklist, counted 32 certificates issued to the attackers between Sept. 22 and 27. From public data, the outlet suggests Ghana was compromised first on Sept. 22 UTC, then Sierra Leone on the 25th and American Samoa on the 27th.
It says most certificates on each day were issued within a 90-minute window.
iTnews also reports that the attackers used free wildcard certificates from Let’s Encrypt and ZeroSSL, plus one Cloudflare CA certificate for a domain of another major tech brand. It says the ccTLD operators did not respond to its requests for comment.
Google's guidance and planned changes
Google advises domain owners to monitor CT logs across their whole portfolio, including parked and regional ccTLD domains. It also recommends restrictive Certification Authority Authorization (CAA) records, which list which CAs may issue for a domain, bound to authorized ACME accounts and validation methods. ACME is the protocol automated CAs use to issue certificates.
Google says CAA records cannot stop issuance during an active hijack. Restoring a restrictive CAA policy afterward, it says, prevents attackers from reusing cached domain control validation results to get new certificates.
Google says it will pursue longer-term HTTPS changes, such as shorter certificate validity and less reuse of domain validation results. It plans to do so through the Chrome Root Program and the new Chrome Quantum-resistant Root Program, per Infosecurity Magazine, Help Net Security and BetaNews.
Why it matters
The incident, as Google describes it, shows attackers can get valid HTTPS certificates for major brands by compromising DNS infrastructure run by third parties, without breaching the brands’ own systems. Google’s caveats, that browser-side blocking is Chrome-specific and its list of victims may be incomplete, are why its guidance points domain owners to CT log monitoring and CAA records. Still open are the intrusion method, the identity of the attackers and the total certificate count.

Join the discussion