DNS Hijacks Led to Unauthorized Google and YouTube Certificates Across Three ccTLDs

Attackers compromised third-party operators associated with the .gh, .sl and .as country-code top-level domains, changed authoritative DNS records and obtained unauthorized HTTPS certificates covering Google and YouTube names.

Google said the incident did not involve a breach of its systems. The company also said it had no reason to believe the certificate authorities that issued the certificates had acted improperly.

The date of the hijacks was not provided. Google learned about the activity in the week before its October 6 post and said it responded immediately. The story was reported on October 7, 2026.

A Certificate Transparency review by The Hacker News found at least 12 domain-validated certificates covering seven Google and YouTube domains. Those certificates first appeared in public logs on September 22, September 25 and September 27.

The available evidence establishes unauthorized issuance, but not abuse against users. Neither Google nor the certificate review confirmed that attackers used the certificates to impersonate a website, intercept traffic or collect information.

Authoritative DNS changes preceded certificate issuance

Certificate authorities issue domain-validated certificates after checking that an applicant controls the requested domain. DNS-based validation is one possible method, but the reporting does not establish precisely how the checks were completed in this incident.

What is established is that the attackers altered authoritative DNS records after compromising third-party operators connected to the three ccTLDs. The DNS changes pointed affected domains to infrastructure under the attackers’ control, and unauthorized certificates were subsequently issued for Google and YouTube names.

A valid certificate could enable an attacker-controlled destination to present an encrypted connection for the covered name without the certificate mismatch warning users would normally encounter. The operator could then serve arbitrary content, potentially including a convincing imitation of the legitimate site.

That is the potential impact, not a confirmed outcome. The sources do not show that any certificate was deployed to impersonate Google or YouTube, or that private data was exposed.

Google did not identify the attackers or explain how the third-party operators were compromised. It also did not state whether the affected domains had been secured.

The risk was not necessarily limited to Google. According to the company, Certificate Transparency data revealed certificates that appeared connected to the same attacks and involved organizations believed to have been affected, including major global brands and widely used online services. Google did not name them.

That statement does not mean every domain under .gh, .sl or .as was compromised.

Public logs revealed at least 12 certificates

The Hacker News searched ctlogs.dev and Cert Spotter on October 7. Its limited review identified 12 certificates for youtube.com.gh, google.com.gh, google.sl, google.com.sl, youtube.sl, google.as and youtube.as, including wildcard and www entries.

Let’s Encrypt issued 11 certificates, while ZeroSSL issued one. Matthew McPherrin, a Let’s Encrypt staff member, confirmed on the CA’s community forum on October 7 that certificates for Google and YouTube had been issued and revoked.

No time zone was specified for those timestamps. Cert Spotter showed all 12 certificates as revoked on October 7.

The reviewed records extended back to at least September 10. For google.com.gh, google.sl and google.as, every other certificate found in those records had been issued by Google Trust Services, Google’s certificate authority.

The search covered only a limited selection of Google and YouTube names. The count of 12 therefore describes the certificates found in that review, not the complete scale of the incident.

Google used Chrome’s emergency blocking system

Google said it blocked the unauthorized certificates for its properties through CRLSets, Chrome’s mechanism for rapidly rejecting selected revoked or untrusted certificates. It also worked with the issuing authorities to revoke the certificates, extending the response to other browsers and applications that process the relevant revocation information.

After examining Certificate Transparency logs, Google blocked additional certificates that appeared connected to the attacks. It contacted organizations believed to have been affected where possible.

Google said Chrome users did not need to take action. However, it warned that its analysis might not have identified every affected domain and that Chrome’s interventions do not reliably protect users of other browsers.

The revocations limit the certificates’ continued usefulness in clients that receive and enforce the updated status. They do not establish whether any certificate was used before revocation.

No affected-user count or confirmed-victim total was reported.

Certificate fingerprints can support defensive searches

Security teams can use the following SHA-256 fingerprints to locate the 12 reported certificates in Certificate Transparency services, certificate inventories or relevant telemetry. Their order matches the table above.

0357032e1214ae11d7da8e00f6b89fb7694e240b17d05f2f47feaf43e96aa7d8
8886ca2b71501a6729f1ae868bd7d7b9b53c5cb6b5c7d851d041db4d6206945d
986d36b1c68c3e800596c4680dd6c67c42118955e08b472f641793c59dcd347b
2e1f6d7f24650b0720636efe48f2ccf59704ee6f11ffa52b5a4c4afcc474fe91
e1667fe4e4ea98427960ea2eda7c53af1246ec58ac22282a6877d394a0957065
e1e4fd74f673f1df9c039ae6424b36868a0475a043abea2dedd1f6f12a365ebf
5b7c491c8784eb438b1634981f1ea6333d3557431268233c2a7a92173ca17122
a10d3b5dbc142d040e6ae772ab41dc44b0e94659237709d1241fdefdd36f7b35
491f453d208bbb7923626c208df93c95fdfae3b78b738b996c8dafda9d00619a
798079c762496d26ce99d3a9113cb24715e31ec8a69a6cdcffa70f5001e19df0
607afd2745b84c4332e028262937be35f25316aadf584340269d23a3dbcd37ef
b7ea8c77695cf9791a9d45f17c33ebb9bd5f68d4c96df6f56136dc6a834576d2

A match identifies one of the certificates reported in the review. It does not prove that a user connected to an impersonation site or that information was intercepted.

Domain owners should inspect regional and parked names

Google recommended monitoring Certificate Transparency logs across complete domain portfolios, including parked domains and regional ccTLD registrations. Owners of names under .gh, .sl or .as should examine recent entries for certificates they did not request.

An unrequested certificate can be submitted to its issuing CA through a Certificate Problem Report. Under the CA Baseline Requirements, the CA must investigate and provide initial findings within 24 hours.

Google also recommended restrictive Certification Authority Authorization records. CAA can limit issuance to approved CAs and, where supported, to authorized ACME accounts and validation methods.

CAA cannot prevent issuance during an active authoritative-DNS hijack if the attacker can remove or falsify the record. Its protection becomes relevant after legitimate DNS control is restored, because a CA may reuse a previous successful domain validation for subsequent requests.

Google said a strict CAA policy can block further certificates based on that cached validation. On October 7, Google Public DNS returned CAA records for all seven identified domains that named only pki.goog, the Google Trust Services domain. The reporting did not establish when those records were added.

The maximum validation-reuse period remains 200 days under the schedule approved by the CA/Browser Forum in April 2025. It falls to 100 days in March 2027 and 10 days in March 2029. Let’s Encrypt said in December 2025 that it reused a domain check for 30 days and planned to reduce that period to 7 hours by 2028.