On Tuesday, 6 October 2026, Google posted a short notice on its blog. No person signed it; the byline was the “Chrome Secure Web and Networking Team”. The notice named three places, or rather their two-letter suffixes: .gh for Ghana, .sl for Sierra Leone, .as for American Samoa. Two West African republics and a US territory in the South Pacific, which on most days have nothing to do with one another. The week before, they had one thing in common. Attackers had seized the registries that keep order in their corners of the internet.
With that control, as Dan Goodin reported for Ars Technica, the attackers obtained counterfeit TLS certificates for Google domains and for sites belonging to other organisations. These are the documents a browser checks before it trusts that it is speaking to the real Google, the real bank, the real mail server.
The keeper of the ledger
A country-code registry is a kind of land registry. It does not own the houses, but it keeps the book that says which name belongs to which address, and everyone else trusts the book. Having taken three of those books, the attackers rewrote the IP addresses for a chosen list of websites. Once traffic for those sites ran through their hands, they changed authoritative DNS records and nameserver delegations for selected domains. Then they applied for certificates.
Before a certificate authority issues a certificate, the applicant has to prove control of the domain. The authority asks its question and waits for the answer to come back from the domain. The attackers held the line, so the answer came from them.
Nobody broke into Google. Nobody broke into the certificate authorities.
In its statement on the hijacks, Google said the incidents “did not involve a compromise of Google’s systems” and that it had “no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.” According to Ars Technica, the company also said the authorities had met every requirement and that none of the affected domain owners’ own infrastructure had been breached.
A reflection, not a finding: every system of trust eventually rests on some clerk’s ledger, and the powerful tend to guard their own walls while the ledger sits somewhere else. The rules were followed and the guards did their work. The forgery got through because, at the moment of checking, the forger was the one who answered.
Blocking instead of revoking
Google says Chrome blocked the unauthorised certificates for its own properties straight away through CRLSets, its mechanism for shutting out specific certificates quickly, and worked with the issuing authorities to revoke them. Revocation also protects people who use other browsers. Formal revocation is slow and cumbersome, Ars Technica notes, and that is why browser makers built faster ways to block individual certificates inside the browser.
Chrome then searched the Certificate Transparency logs, the public records of issued certificates. There it found more victims, “including several leading global brands and widely used online services,” in Google’s words. It blocked those certificates too and contacted the organisations where it could. “Chrome users do not need to take any action to be protected,” the company wrote.
What the company would not promise
The same statement carried a warning addressed to everyone else who runs a website:
While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users. Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.
A good deal is still unknown. Ars Technica reported that it was not immediately clear who the other affected organisations were, how many unauthorised certificates had been issued, or whether every certificate outside Google’s own domains had been blocked. With all known certificates blocked, the risk is reduced. The ones nobody has found are still a threat.
Google’s advice to domain owners was practical. Watch the transparency logs continuously across every domain you hold, including parked domains and regional country-code ones. Anyone holding a .gh, .sl or .as name should check recent log entries for certificates they never requested. Publish restrictive CAA records with ACME account bindings, which limit which authorities, accounts and validation methods can issue for a domain.
Google admits that CAA records cannot stop issuance while a hijack is under way. They matter afterwards, once DNS control has been recovered, because certificate authorities may reuse cached domain validation, and an attacker could otherwise use that leftover state to get fresh certificates. Over the longer term, the company says it will push for shorter certificate lifetimes and less reuse of validation, through the Chrome Root Program and its new Chrome Quantum-resistant Root Program. That second effort belongs to a wider industry shift, which already includes Cloudflare’s plan to issue quantum-resistant certificates from 2027.
Fifteen years after DigiNotar
This has happened before. In 2011 attackers broke into DigiNotar, a certificate authority in the Netherlands, and produced counterfeit certificates for Google.com and more than 200 other heavily used domains. Ars Technica recalls that the certificates were used against at least 300,000 people with ties to Iran while they browsed the impersonated sites. Hardware Busters puts the number of forged DigiNotar certificates at 500. There have been many similar cases since, most of them failures by certificate authorities and some by domain holders.
The 2011 attackers broke into the authority that issues certificates. This time they went one level higher, to the registries whose records the authorities rely on for their checks. Ghana, Sierra Leone and American Samoa run three of those registries.