By Morrow, analyst · TL;DR
On Oct 25 eMudhra told Mozilla's bug that revocation of its eight compromised intermediates "has been available via CRL and OCSP" and that a relying party that checks it "has not been exposed since the revocation." Its own incident report on Bug 2085612 says a firewall profile on its CRL, OCSP and repository hosts was refusing curl, Wget, Python-urllib and libwww-perl at the time. On Nov 9 eMudhra wrote that the correction "will be posted in the updated Full Incident Report" (c8). As of the latest comment on Bug 2083449 (c81, 12:29 UTC today), that report isn't posted.
Our read: when anyone can recompute a CA's keys, revocation is the remedy left for software that still trusts the chain, and eMudhra's change review treated the hosts serving it as a website. That's the arrangement, and it isn't unique to one CA.
If you run a CA, internal PKI included, fetch your own CRL, OCSP and CA-certificate URLs with the User-Agents a script would send (commands below). A 403 for curl and a 200 for another User-Agent is this bug.
Claim Ledger
✅ Confirmed: eMudhra (Bug 2085612 c3, Oct 29): the filter "came from a generic bot and scanner protection profile, configured by the WAF vendor and applied to the whole host, with no exception for revocation and repository paths." Non-compliance start date "2022-09-28"; end "2026-10-26 10:32 UTC". The affected CRLs included roottlscag3.crl and rootcscag3.crl, "which carry the eight cACompromise revocations from Bug 2083449."
✅ Confirmed: eMudhra (c8, Nov 9): the change review "treated the WAF as a website control. It did not consider TLS BR 2.4, 4.9.7 or 4.10.2, or CP/CPS 2.4, and PKI compliance was not a required reviewer." Its monitoring, Oct 18–26: 78,820,450 requests to the four CRL and OCSP hosts, 1,658,756 "Denied by firewall" (2.10%). Its first response came "about 100 hours after the issue was raised, which is outside the CCADB expectation."
✅ Confirmed (our check): 14:33–14:42 UTC today, from one machine in the US,
curlfetches (several User-Agents) ofhttp://crl.emsign.com?roottlscag3.crland?rootcscag3.crl: 15 of 50 failed (11 reset at about 10.5 seconds, 4 with no response in 25).repository.emsign.com's front page: 4 of 8 reset. Controls interleaved in one run: eMudhra's separatecrl-chost and a DigiCert CRL, 8 of 8 each. In a run with five User-Agents, no firewall page came back. roottlscag3.crl, saved and parsed with OpenSSL, was last updated Oct 18.🗣️ Claimed: An outside commenter on Bug 2083449 (c44) says 107,107 certificates signed with six of the eight keys were logged to CT on Oct 20–21, "all but two" with no revocation pointer. Per that comment, only clients that check every CA certificate in the path, receive a pushed blocklist, or have dropped the roots reject them.
❓ Unknown: When the final report lands, and what its corrected impact statement says. How many of the 1,658,756 denials were revocation checks rather than scanners. Whether today's resets are what c8 describes as corrected.
I think the change ticket matters more than the weak keys. A firewall profile deployed in 2022, and reviewed as a website control, sat in front of the one service that still mattered once the keys were out. What would prove me wrong: a final report showing that people who weighed the Baseline Requirements put that profile on those hosts on purpose. Then it was a bad call, not an arrangement. c8 says the opposite, so far.
What eMudhra said, and when
On Oct 25 at 03:53 UTC, in comment 43, eMudhra answered the Chrome Root Program's charge that it was putting reputation first. Its fourth point was about harm: "Revocation status has been available via CRL and OCSP since that point." A relying party that checks revocation "has not been exposed since the revocation." If anyone remains exposed, "the exposure is a property of that software and would apply identically to a key compromise at any CA."
Thirty minutes later, comment 44 showed curl getting a 403 on roottlscag3.crl, the CRL that lists the six revoked TLS intermediates, and a 200 with another User-Agent. eMudhra's own report on the separate bug confirms it: four common HTTP clients were refused on the CRL, OCSP and repository hosts from 2022 until Oct 26.
c43 said the software still exposed was software that doesn't check. For four clients, checking didn't work, because eMudhra's firewall refused them. They aren't browsers, and browsers had another remedy: per eMudhra's Nov 5 earnings call, "the browser programs have distrusted the related route." The four are, in eMudhra's own words below, "common command-line and script HTTP clients".
The sentence that carries it
eMudhra's c3 analysis is better than its c43 argument: "The signatures are meant for web applications. They block common command-line and script HTTP clients because scanners often use them. Revocation and repository services exist to be fetched by software, so these clients are legitimate users of them."
That's the arrangement in three sentences. A WAF vendor ships a bot profile, it protects websites from scanners, and somebody applies it to "the whole host". The c8 answer names the gap: the review "did not consider" the Baseline Requirements sections on repositories and CRLs, and "PKI compliance was not a required reviewer." The fix eMudhra now lists, due Oct 26 and marked "Complete", is a security policy for the CRL, OCSP and repository endpoints, "separate from website WAF profiles", with PKI Compliance as "a mandatory approver" and a checklist against BR 2.4, 4.9.7, 4.10.2, 7.1.2.11.2 and CP/CPS 2.4.
Where it stands this morning
eMudhra set Nov 9 itself, in comment 73: "We will need an additional week (Nov 9th, 2026) before we share the full incident report." The CCADB's rules say a full report "MUST be posted within 14 days" of initial disclosure, and that an impact found inaccurate requires the CA to "clearly communicate a correction". A commenter asked for it on Nov 9, and another asked for a status update today. eMudhra hasn't replied there since c73 on Nov 2.
Then our check. The User-Agent filter is gone: no firewall page, for any of five clients. But eMudhra's c8 describes the other failure, on the same two addresses: "Requests were accepted and then reset after about 10.5 seconds without a response, for every User-Agent." Today we saw that shape on 11 of the 15 CRL failures and all 4 at the repository, and no failures on the controls. Our read: c8 follows that sentence with "We corrected it at 2026-10-26 10:32 UTC", and the failures a commenter posted in c5 were measured on Oct 29, after it. Either "it" is the filter, or the fix didn't hold.
What to do
If you run a CA, public or internal (an AD CS CDP, an OCSP responder behind a CDN), test the URLs in your own certificates the way software fetches them. This is adapted from the method a commenter posted in c1, and we ran it today:
URL='http://crl.emsign.com?roottlscag3.crl' # put your own CDP/AIA/OCSP URL here
for ua in curl/8.7.1 Wget/1.21.4 Python-urllib/3.12 libwww-perl/6.72 check/1; do
printf '%-20s ' "$ua"
curl -s -o /dev/null -m 20 -A "$ua" -w '%{http_code} %{time_total}s\n' "$URL"
done
curl -s -m 20 "$URL" | openssl crl -inform DER -noout -lastupdate -nextupdateDifferent codes by User-Agent is the filter. 000 near 10 seconds for every client is the reset c8 describes. Then find the change ticket that put a bot profile on that host, and see who signed it.
The newsroom argued
Morrow: My first TL;DR said eMudhra's compromised-CA revocation "is still not reliably reachable." Fifteen of fifty is not reliable. Salem: Fifty requests, one machine, under ten minutes. That's a reading, not a property of the service. And the failures hit curl and a made-up client alike, so it's a different fault from the filter c44 found. Don't let a reader merge them. Morrow: Then the counts go in the ledger with the scope, and the TL;DR keeps the filter. Ames: Salem's scope stands. The counts run as our check, with the controls next to them. "Still not reliably reachable" doesn't.
What we passed on
N-able N-central: N-able took hosted N-central offline after a researcher published more than 30 alleged zero-days, and says on-prem servers should stay offline until patches ship; it expected a fix "around midday on November 10" and says it has no evidence of exploitation against its N-central environments, per SecurityWeek (N-able's statement not read at source).
OpenSSH "SSHole", CVE-2026-123158: our Nov 9 line said "exploitation attempts", per SecurityWeek. Overtaken: CISA added it to KEV on Nov 9, due Nov 12, and GreyNoise says it saw successful exploitation from Nov 7 (BleepingComputer). Patch and restart sshd.
Chrome CVE-2026-125350: "Google is aware that an exploit for CVE-2026-125350 exists in the wild." Update Chrome; BleepingComputer gives 157.0.8103.50/.51 on macOS and 157.0.8103.50 on Linux (BleepingComputer; Google's advisory not read).
Barracuda ESG CVE-2026-116606 and CVE-2026-111560: Barracuda now says it has "identified exploitation activity affecting a small number of organizations." Confirm the patch applied and restrict the admin interface to trusted internal networks, as Barracuda advises (BleepingComputer; advisory not read).
France attributes the Oct 11–12 refrigeration attack, which targeted controllers at "environ 700 sites", to the IRGC's Shahid Kaveh unit, citing Modbus/port 502 reconnaissance and Farsi traces (CERT-FR). The US fact sheet's check: "Review setpoint ranges" and alert on deviations (CISA fact sheet).