The takeaways, in brief
- In the first Internet-scale analysis of its kind, a joint Google-GitGuardian study matched 945,560 leaked private keys to 139,767 TLS certificates using Certificate Transparency logs.
- More than 900 valid certificates belonged to Fortune 500 companies, healthcare organizations, and government agencies, with 84 certificates still unrevoked as of January 2026 despite direct notification.
- All 2,622 compromised certificates shared one trait: the private key existed as an extractable file. Hardware-bound, non-exportable keys — generated inside TPMs and HSMs — eliminate this class of exposure entirely.
One Million Keys and 2,622 Live Certificates
Researchers at GitGuardian spent four years scanning public code repositories and container registries for leaked cryptographic key material. The result: approximately 1 million unique private keys exposed across GitHub and DockerHub since 2021.
Using Google’s infrastructure for scanning the Certificate Transparency (CT) database — a public ledger containing more than 5 billion unique certificates across more than 10 terabytes of storage — the team matched leaked keys to real TLS certificates. As of September 2025, 2,600 of those certificates were still valid and actively protecting live websites.
The researchers presented their findings at Real World Crypto (RWC) 2026 in Taipei, in a session titled “Private Key Leaks in the Wild.” The audience — several hundred cryptographers and security engineers — heard what the researchers called “a systemic failure, not isolated incidents.”
An attacker who obtains a website’s private key can impersonate that website, intercept encrypted traffic, and manipulate data in transit.
The Study: From GitHub Scan to Certificate Match
The methodology connected two functions that had never been linked at scale: GitGuardian’s detection of private keys leaked on public repositories and images and Google’s infrastructure for querying the Certificate Transparency database. Here’s how it worked:
Step 1 — Key collection. GitGuardian’s secret detection engine continuously scans public GitHub repositories and DockerHub container images. Since 2021, it has flagged roughly 1 million unique private keys — RSA, ECDSA, and other asymmetric key types embedded in committed code, configuration files, and Docker image layers.
Step 2 — Public key derivation. For each leaked private key, researchers computed the corresponding public key. This is a deterministic mathematical operation: a private key produces exactly one public key.
Step 3 — CT log matching. Every publicly trusted TLS certificate is logged in CT logs, append-only public ledgers defined by RFC 6962 and originally created in response to Certificate Authority (CA) compromises like the 2011 DigiNotar breach. Each certificate entry contains its public key. Researchers searched Google’s CT database for certificates whose public keys matched the derived public keys from leaked private keys. The result: more than 40,000 key-to-certificate matches across 140,000 certificates.
The RWC 2026 presentation refined these figures: 945,560 leaked private keys mapped to 139,767 certificates.
Step 4 — Validity assessment. The team then verified which certificates were still valid using two methods: direct online TLS checks for 921 certificates (35%) and simulated TLS stack validation for the remaining 1,701 certificates (65%). The combined count: 2,622 valid certificates with publicly leaked private keys.
Step 5 — Attribution. Finally, the researchers extracted domains from certificate Subject Alternative Names, scraped security.txt files, analyzed Whois and MX records, and deployed AI-assisted web crawling to identify responsible organizations. Only 430 certificates (16% of valid certificates) included organization information in their certificate fields; 1,300 certificates remained untraceable.
What They Found: Fortune 500, Government, and Healthcare Exposed
It turned out that more than 900 valid certificates belonged to Fortune 500 companies, healthcare providers, and government agencies. These certificates were actively protecting production websites for some of the largest organizations in the world.
At the exact moment their private key was leaked, 24,000 of those certificates (17.16% of all mapped) were valid. And the exposure rate isn’t slowing down. The researchers estimated 4,000 to 5,000 certificates are compromised every year due to leaked private keys.
The Single-Digit Response Rate
The researchers began disclosing their findings to the impacted enterprises in late 2025. They sent 4,300 emails to 600 organizations about their exposed certificates, expanding to 1,706 total entities including CERTs and CAs.
Out of those 600 organizations, just 54 organizations responded — a 9% response rate.
When researchers focused on certificates with high-confidence organizational attribution, the response rate improved. But across the broader disclosure effort, nine out of 10 organizations either never received the notification, ignored it, or didn’t understand what it meant.
The researchers contacted 20 national CERTs — the government computer emergency response teams designed to coordinate exactly this type of disclosure. Only two responded within one week.
Three bug bounty programs asked the researchers to prove that having a website’s private key was actually a security problem. That question alone — from organizations running formal vulnerability disclosure programs — signals a deep misunderstanding of certificate private key security in the broader industry.
Why Private Keys End Up in Repositories
The root cause is straightforward: Private keys exist as files, and files end up in version control.
Developers include .pem, .key, and .p12 files alongside application code. .gitignore rules are missing or misconfigured. Docker images embed private keys for TLS termination or mutual TLS authentication. When those images are pushed to public registries, the keys go with them. CI/CD pipeline configurations store key material in plaintext. Developers copy production certificates into test environments and forget to remove them before committing.
GitGuardian’s State of Secrets Sprawl 2026 report provides context for the scale of this problem. In 2025, developers committed nearly 28.65 million new hardcoded secrets to public GitHub repositories — a 34% year-over-year increase. The remediation gap compounds the exposure. 64% of valid secrets from 2022 remained active and exploitable in January 2026. Private keys don’t expire on their own. Without active revocation, a key leaked in 2022 is still usable years later.
The Revocation Failure
Even after detection, the remediation path broke down at every step.
Organizations Didn’t Self-Remediate
The 9% response rate to 4,300 disclosure emails is the headline number, but the breakdown is worse. Most organizations had absolutely no process to detect or respond to private key exposure.
Certificate Authorities Had to Step In
After organizations failed to act, the researchers escalated directly to certificate authorities. They submitted 2,200 certificates to CAs for revocation. Most CAs acted within 48 hours, and the overall remediation rate reached 97%. But that 97% masks the extraordinary effort required to protect organizations that failed to protect themselves in the first place.
How to Reduce the Risk of Private Key and Certificate Exposure
The GitGuardian and Google researchers’ core recommendation is direct: “Cryptoperiods must be shortened, and private keys should never outlive certificates; ideally, they should be single-use.”
Thankfully, the industry is already moving in that direction. The CA/Browser Forum passed Ballot SC081v3 in April 2025 without opposition, setting a phased reduction schedule for maximum TLS certificate lifetimes. By 2029, domain validation data can be reused for a maximum of 10 days. The era of long-lived certificates is ending.
