Here is the entry point for the answer: open emudhra.we-have-a-problem.com and click Run check. If any red shows up in the table, your browser still trusts the eight eMudhra intermediate certificates whose private keys have leaked — which means, in theory, any site you visit could be swapped for an attacker-signed high-quality fake. There is only one remedy: update. Bring your browsers and operating systems to the latest versions.
The checker's approach is almost brutally simple: it serves HTTPS certificates signed by the "broken CAs" themselves. Each of the eight intermediates gets a subdomain, with the certificate chain anchored under the compromised intermediate. When your browser connects:
- Connection fails / certificate error → good news, your browser has already blacklisted these intermediates.
- Page loads fine, red lights up → your browser still accepts the chain.
- Firefox and Chrome: blocked on October 17
- Apple: October 19
- Microsoft: October 20
The same works from the command line: curl https://dv-g3b-emudhra.we-have-a-problem.com/ — a certificate error means safe; content returned means your curl still trusts the bad CA. In the certificate world, errors are rewards.
Where the site came from
The researcher who discovered the eight leaked keys goes by Wayne. On October 17, he signed the same message with every leaked key: "We have a problem here - Wayne", and submitted it with evidence to the major root programs. That message is now the domain: we-have-a-problem.com. The evidence package is public on the site — two openssl commands, verifiable by anyone. This is disclosure done the standard way: not merely asserting "the keys are weak," but placing the signatures there so the claim and the proof arrive together.
Browsers are largely safe
Chrome's CRLSet, Mozilla's OneCRL and CRLite, plus Apple's and Microsoft's system-level blocklists push revocations automatically:
The long tail is outside browsers
Go's approach last week was to hard-code the eight public key hashes into the standard library, but the entire non-browser world has to ship its own release. The checker maintains a "who's fixed" list — Ubuntu, Debian, Fedora, and Arch system trust packages, curl's CA bundle, all Java versions, three Node.js major versions, Python's certifi, Rust's rustls-webpki, Perl, Deno, Electron — even Claude Code, which ships its own trust store, has a fixed version on the list. Two entries are still pending: Bun and Erlang's certifi.
The trickiest case is macOS: the OS-level block is in place, but the bundled curl, git, and python3 validate certificates against /etc/ssl/cert.pem — a file that does not check revocations and does not update with the system. The site provides a manual awk command to remove the bad roots from that file yourself. Wherever the push chain breaks, trust stops there.
A number worth remembering
The checker's server records every successful handshake — every client still trusting the bad CA adds a row to the stats page, tagged with user-agent and JA4 fingerprint. In its first twenty minutes online, it logged about 19,000 connections. How many are unmaintained CI scripts, old containers, or outdated runtimes is unknowable. That is the silent part of incidents like this: what got compromised is not a particular server, but a piece of trust hanging in mid-air — unreachable by any push channel and viewed by no one.
References: emudhra.we-have-a-problem.com (check entry, evidence package, fix tracker, live stats); Mozilla bug 2083449; the Go fix post from that morning.