💡 This post is a companion piece to our presentation at Real World Crypto (RWC) 2026 in Taipei, Taiwan on March 11, 2026, where GitGuardian and Google researchers will present the full findings of this collaboration. When a private key leaks on GitHub or DockerHub, detecting it is easy. What's harder, sometimes impossible, is understanding its real-world impact. Unlike AWS keys or OpenAI tokens, which are tied to their respective service, a leaked private key is just a mathematical object without an obvious owner. Private keys are challenging to attribute at scale: they are used in many different contexts, ranging from SSH authentication to JWT signatures. When one leaks, where do you start assessing the impact? Among leaked private keys, those used in X.509 infrastructure are most critical. They authenticate web servers in HTTPS: a compromised key enables attackers to impersonate websites or intercept data. That's why GitGuardian partnered with Google's researchers to answer a deceptively simple question: what happens when private keys leak? In the TLS ecosystem, a private key leak poses a critical threat, as attackers on the appropriate network path can impersonate websites, intercept or manipulate data, and decrypt past communications, particularly if the same private key is used for a long period of time prior to the widespread adoption of PFS. The Numbers Behind the Threat Since 2021, GitGuardian has detected about one million unique private keys leaked across GitHub and DockerHub. Using Google's internal Certificate Transparency database, we successfully mapped more than 40,000 of these keys to 140,000 real TLS certificates. As of September 2025, 2,600 of these certificates were valid , with more than 900 actively protecting Fortune 500 companies, healthcare providers, and government agencies. Our disclosure campaign revealed worse news: we sent 4,300 disclosure emails to 600 organizations about their exposed certificates, but only 54 responded . That's a 9% response rate. Even for high-confidence identifications, only 36% bothered to reply. National CERTs? Only 2 out of 20 responded within a week. Bug bounty programs? Three asked us to prove that having a website's private key was actually a security problem . Research pipeline This reveals a widespread misunderstanding of private key risks . Months after disclosure, 84 certificates remain valid; 40% from Certificate Authorities (CA) we contacted but who failed to revoke. This is the first Internet-scale analysis of private key leaks, made possible by combining two unique capabilities: GitGuardian's real-time secret detection across millions of repositories and images, and Google's infrastructure for querying Certificate Transparency logs containing billions of certificates. Certificate Transparency (CT) is a public database of all certificates issued by major CAs since 2015, created after CA compromises like the 2011 DigiNotar breach. CT is a decentralized architecture with multiple operators hosting what are called logs , subsets of the CT database. In theory, CT is perfect for mapping leaked keys to certificates using public key hashes. The mathematical properties of asymmetric cryptographic keys make it easy to link a certificate’s public key information with its corresponding private key. In practice, storage and persistence are massive challenges. In 2025 alone, over 5 billion unique certificates have been submitted, representing more than 10 terabytes of storage. Moreover, log operators can disconnect logs once all their certificates have expired, which makes sense in the context of TLS but breaks OSINT and historical attribution. As of September 2025, 2,600 of the mapped certificates were valid (6% of mapped keys). We validated 921 (35%) through direct online checks; the remaining 1,701 (65%) required simulated TLS stack validation. Querying TLS revocation mechanisms revealed a widespread misunderstanding of the impacts: of all the certificates we found compromised, only 24 were revoked via Certificate Revocation Lists (CRL) – with just 1 marked as actually compromised – and 56 via OCSP – with only 2 marked as compromised. More troubling: nearly 22% of offline-validated certificates were found to differ from those served online. This usually indicates that a new certificate has been issued after the key leak, without revoking the compromised one. Owners either don't know about the leak or don't understand revocation. Finally, since revocation is rarely used, we simulated historical validity by checking if the private keys leaked during their associated certificate's lifetime. This revealed that 24,000 certificates (17.16%) were valid at the time of the leak, and more than 4,000 are exposed per year. Valid certificates at the time of first leak (in September 2025) Responsible Disclosures With certificates mapped, the next challenge emerged: finding and contacting their owners. Mapping private keys to certificates was indeed easy. Finding who o...