Google has confirmed that attackers compromised three country-code domain registries and used the hijacks to obtain 12 unauthorized HTTPS certificates for Google and YouTube domains. Google’s own systems were not breached, but the incident put every domain under .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) at risk. With one of those certificates, an attacker could have impersonated Google over an encrypted connection and read the private data people sent to it. All 12 certificates have since been revoked and blocked in Chrome, but Google says other well-known brands were hit by the same attackers too.
This article breaks down what happened, which certificates were issued, how the attack worked, what Google did about it, and what domain owners should do now.
What Happened: The Short Version
On October 6, 2026, Google disclosed that attackers had compromised the registries behind three country-code top-level domains: .gh, .sl and .as. During the hijacks, the attackers changed the authoritative DNS records for Google and YouTube domains under those extensions. Because domain-validated (DV) certificates only require the applicant to prove control of a domain, usually by adding a DNS record, the attackers were able to get 11 certificates from Let’s Encrypt and one from ZeroSSL for names like google.com.gh, google.sl, google.as and youtube.sl.
The certificates were issued over a six-day window between September 22 and September 27, one ccTLD at a time: .gh on September 22, .sl on September 25, and .as on September 27. Certificate Transparency logs show the first .as certificate appeared roughly a day after the .gh certificates were revoked, suggesting the attackers kept working even after their earlier certificates were taken down.
The 12 Unauthorized Certificates
The Hacker News traced the full set of certificates through two Certificate Transparency search services, ctlogs.dev and Cert Spotter, on October 7. The 12 certificates cover seven domains, and every one of them has now been revoked:
- September 22 — two certificates for youtube.com.gh and google.com.gh (Let’s Encrypt), revoked September 26
- September 25 — five certificates for google.sl, google.com.sl and youtube.sl names (Let’s Encrypt and ZeroSSL), revoked between September 26 and October 1
- September 27 — five certificates for google.as and youtube.as names (Let’s Encrypt), revoked October 1
Every record reviewed going back to at least September 10 shows that all other certificates for these domains came from Google Trust Services, Google’s own certificate authority. The unauthorized ones were the only outliers. A Let’s Encrypt staff member confirmed the issuance and revocation of the certificates in the company’s community forum on October 7.
One important detail from the CT data: only a small set of Google and YouTube names was searched, so the real total may be higher. Google also said its CT analysis pointed to other organizations hit by the same attackers, including well-known global brands and widely used online services. It did not name them, but said it blocked those certificates in Chrome and contacted the affected organizations where it could.
How the Attack Worked
To understand this incident, it helps to separate the three layers involved: the domain registry, DNS, and the certificate authority.
The registry compromise
A domain registry is the organization that maintains the master list of domains under a top-level extension. When an attacker compromises a registry or a registrar-level system, they can change which name servers are authoritative for any domain under that extension, or even alter delegation records directly. Google did not say how the .gh, .sl and .as registries were compromised, whether the attackers got in through a registrar account, a registry portal, or somewhere else. It also has not confirmed whether the registries have been fully secured.
The DNS hijack
Once the registry-level control was in place, the attackers changed the authoritative DNS records for the target domains. This is the critical step: a DV certificate check asks the applicant to prove they control the domain, usually by placing a specific token in a DNS record or serving a file at a known URL. With DNS under their control, the attackers could answer those challenges trivially. Google has stated it has no reason to believe the certificate authorities did anything wrong here. The CAs followed the correct process; the process was simply undermined by the DNS hijack upstream.
The certificate issuance
With DNS control established, the attackers requested DV certificates and passed the domain-control checks. DV certificates are deliberately lightweight: they verify domain control, not organizational identity. That design makes them fast and free to obtain, which is exactly why Let’s Encrypt can issue millions of them. But it also means a hijacked domain plus a compliant CA equals a valid-looking certificate for someone else’s name.
The incident follows a pattern security teams have seen before in smaller incidents: DNS-layer attacks converting a domain compromise into trusted TLS credentials. This latest wave, like the F5 BIG-IP zero-day we covered in September, shows that the most dangerous weaknesses often sit one layer below where most teams are looking.
How Google Responded
Google said it learned of the hijacks the week before its October 6 disclosure and acted immediately, though it did not publish exact dates for the hijacks or for its own response actions. The response had several parts:
Chrome-level blocking
Google blocked the unauthorized certificates for its own domains through CRLSets, Chromium’s emergency mechanism for pushing certificate blocks to Chrome users quickly. This protects Chrome users, but Google was clear about the limits: CRLSets do not reliably protect people using other browsers or apps.
Revocation
Google worked with the issuing CAs to revoke all 12 certificates. The .gh certificates and the ZeroSSL certificate were revoked on September 26, the remaining nine on October 1. The gap between issuance and revocation ranged from about a day and a half to nearly a week, during which the certificates were live in Certificate Transparency logs and technically usable.
Warning other victims
Google also blocked in Chrome the certificates it found for other organizations and reached out to those organizations where it could. It did not identify the attackers and said it could not guarantee its analysis found every affected domain, because DNS hijacks are complex to fully reconstruct.
Why This Matters Beyond Google
The Google certificates were the headline, but the broader lesson is about who else was exposed. Any domain under .gh, .sl or .as was in the blast radius during the hijack windows, and Google believes well-known brands and widely used online services were targeted too. For most organizations, the takeaway is uncomfortable: your TLS security depends on the integrity of every layer beneath your domain, including a registry operator you may never have dealt with directly.
The incident also underlines a structural tension in the certificate ecosystem. Domain-validated certificates are essential to a fast, encrypted web, but they inherit whatever trust the domain system currently has. When the domain layer itself is compromised, DV issuance becomes a weapon. Attackers are increasingly striking within hours of a weakness becoming known, as we saw with the Atlassian CVE-2026-21589 exploitation wave, and this certificate campaign shows the same opportunism applied to internet infrastructure itself.
What Domain Owners Should Do
Google gave domain owners two direct recommendations, and the rules governing CAs add a third option. None of them are complicated, but they only work if they are in place before an incident.
Monitor Certificate Transparency logs
CT logs are the public record of every certificate issued by participating CAs. Free CT monitoring services can send an alert the moment a certificate is issued for any domain you own, including parked domains and regional ccTLD variants. Anyone running a domain under .gh, .sl or .as should review recent log entries right now for certificates they did not request. If you own any domain, monitoring is cheap insurance.
Publish a strict CAA record
A CAA (Certificate Authority Authorization) record is a DNS record that names the specific CAs allowed to issue certificates for your domain. A CA is required to check it before issuing. Google recommends tying the CAA record to your own account at the CA, which works when the CA supports account-bound issuance. Each of the seven hijacked Google domains carried a strict CAA record naming only pki.goog, Google Trust Services’ domain, as of October 7.
There is an honest limitation worth noting: a CAA record cannot stop issuance during an active DNS hijack. An attacker who controls your DNS can delete the record or insert a false one. The record matters once you have control of DNS again. CAs are allowed to reuse a completed domain-validation check for later certificate requests, so an attacker who passed a check during the hijack could request more certificates after it ended. A strict CAA record blocks that follow-on path. Under current Baseline Requirements, a CA can reuse a validation for up to 200 days, dropping to 100 days in March 2027 and 10 days in March 2029. Let’s Encrypt already reuses checks for only 30 days and plans to cut that to 7 hours by 2028.
Report certificates you did not request
Anyone can file a Certificate Problem Report with the CA that issued a suspicious certificate. Under the Baseline Requirements that CAs follow, the CA must investigate and report its first findings within 24 hours. Filing a report is how the revocation process starts.
Google’s own warning bears repeating: Chrome users do not need to do anything, but domain owners should not rely on the browser to protect their users. The protections that worked here, revocation and CRLSets, are reactive. The defenses that prevent the next wave are the ones you set up yourself: CT monitoring and strict CAA records.
FAQ
Were Google’s own systems breached?
No. Google confirmed its systems were not breached. The attackers compromised the .gh, .sl and .as domain registries and hijacked DNS for Google and YouTube domains under those extensions. The certificates were obtained through domain-validation checks answered with the hijacked DNS.
Was any user data stolen using these certificates?
Google’s disclosure does not say whether any of the unauthorized certificates was actually used to impersonate a Google site or read users’ data. The certificates existed and were technically valid for between about a day and a half and nearly a week before revocation. The risk they created is confirmed; actual exploitation is not.
Do Chrome users need to do anything?
No. Google said Chrome users do not need to take any action. Chrome blocked the unauthorized certificates through CRLSets, and the certificates were revoked. However, Google warned that Chrome’s blocks do not reliably protect users of other browsers or apps.
Which certificates did Let’s Encrypt issue?
Let’s Encrypt issued 11 of the 12 unauthorized certificates, and ZeroSSL issued one. A Let’s Encrypt staff member confirmed the issuance and revocation on the company’s community forum on October 7. Google stated it has no reason to believe the CAs did anything wrong; the domain-validation checks were satisfied because the attackers controlled DNS.
Who else was affected?
Google said Certificate Transparency data pointed to other organizations hit by the same attacks, including well-known global brands and widely used online services. It did not name them. Google blocked those certificates in Chrome and contacted the organizations where it could.
Can a CAA record have prevented this?
Not during the hijack itself. An attacker controlling DNS can remove or falsify a CAA record. But a strict CAA record still matters afterward: it blocks an attacker from requesting additional certificates using a reused domain-validation check once the hijack ends. Combined with CT monitoring, it is the best practical defense available to domain owners today.
The incident is still developing: the attackers have not been named, the exact compromise method at the registries is unknown, and Google has not confirmed whether the ccTLDs are fully secured. For comparison with another large-scale incident from this week, see our breakdown of the Revolut data breach, and our coverage of the GitLab AI Gateway critical flaw for a look at how quickly trusted infrastructure can turn into an attack surface.