← Back to Feed CACHED · 2026-10-23 14:57:51 · CACHE_KEY CVE-2026-113470
CVE-2026-113470 · CWE-295 · Disclosed 2026-10-20

Mozilla Firefox/Thunderbird OneCRL blocklist delivery gap for compromised eMudhra intermediate CAs

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Like a fire alarm that works everywhere except in rooms where someone pulled the fuse

CVE-2026-113470 addresses a gap in how Firefox and Thunderbird deliver emergency certificate blocklists. When eight eMudhra intermediate CA private keys were found to be trivially recoverable from their public certificates in October 2026, Mozilla pushed a OneCRL revocation via RemoteSettings within three hours on October 17. However, Firefox installations where the DisableRemoteSettingsAndAcceptSecurityConsequences enterprise policy is active never received that push. Affected versions are Firefox < 158.0.1, Firefox ESR < 153.5.1, Firefox ESR < 115.43.1, Thunderbird < 158.0.1, and Thunderbird < 153.5.1. The October 20 releases bake the updated OneCRL blocklist directly into the binary, closing the gap for policy-restricted installations.

Mozilla's advisory labels this HIGH impact, but the NVD CVSS of 5.4 (MEDIUM) is closer to the mark for this specific CVE. The HIGH rating likely reflects the severity of the *underlying* eMudhra compromise — eight intermediate CA keys (P-384 ECDSA) so weak they can be recovered in under a second, enabling fraudulent certificate issuance for any domain. That is genuinely terrifying. But CVE-2026-113470 is narrower: it only affects the subset of Firefox/Thunderbird users who have deliberately disabled RemoteSettings via a policy with an intentionally alarming name, AND an attacker still needs a man-in-the-middle position to exploit it. The vast majority of Firefox users received the OneCRL block automatically on October 17, three days before the binary fix shipped. The vendor CVSS of 5.4 fairly captures this residual exposure for the restricted population.

"Firefox missed eMudhra cert revocation only when admins disabled RemoteSettings — a narrow gap requiring MitM"
02 · The Attack Path

4 steps from start to impact.

STEP 01

Recover eMudhra intermediate CA private keys

The eight eMudhra intermediate CA certificates (issued April 2025) were generated with catastrophically insufficient randomness on their P-384 ECDSA keys. The private keys are computable from the public certificates in under a second using standard elliptic-curve math. Multiple researchers have independently recovered all eight keys since disclosure, and the values are now effectively public knowledge.
Conditions required:
  • Access to the public eMudhra intermediate certificates (available in CT logs and CCADB)
Where this breaks in practice:
  • None — keys are already public knowledge as of October 17, 2026
STEP 02

Generate fraudulent TLS certificate for target domain

With the recovered private key from any of the six TLS intermediates (EM DV/OV/EV TLS CA - G3B or G3C), the attacker signs a new X.509 certificate for any domain. The fraudulent cert chains through the compromised intermediate to emSign ECC Root CA - G3 or the cross-signed Sectigo AAA Certificate Services root, both still trusted in unpatched stores. No Certificate Transparency log submission is required. Standard OpenSSL commands suffice.
Conditions required:
  • Recovered private key (step 1)
  • Knowledge of target domain name
Where this breaks in practice:
  • CT-enforcing browsers would flag certificates not logged — but this is irrelevant here since the vulnerable population already lacks the OneCRL block
Detection/coverage: CT monitors (crt.sh, Censys CT) would detect any publicly logged fraudulent certificate, but a targeted attacker would not submit to CT logs
STEP 03

Establish man-in-the-middle position

The attacker must intercept network traffic between the victim and the legitimate server. This typically requires ARP spoofing on a LAN, DNS hijacking, BGP hijacking, a compromised Wi-Fi AP or proxy, or a rogue hotspot. This is the highest-friction step in the chain and generally implies the attacker already has local network access or has compromised upstream infrastructure.
Conditions required:
  • Network position between victim and target server (LAN access, rogue AP, compromised router/proxy, or ISP-level capability)
Where this breaks in practice:
  • Requires local network access or infrastructure compromise — not achievable remotely without a prior foothold
  • Enterprise networks with 802.1X port authentication, network segmentation, and IDS/IPS make ARP/DNS spoofing detectable and difficult
  • DNSSEC deployment prevents DNS-level MitM for signed zones
Detection/coverage: Network IDS (Suricata, Zeek) detects ARP spoofing and DNS poisoning; WIDS detects rogue access points; HSTS preload prevents downgrade for major domains
STEP 04

Present fraudulent certificate to vulnerable Firefox client

When the victim's Firefox — running a version below 158.0.1 with the DisableRemoteSettingsAndAcceptSecurityConsequences policy active — connects to the target domain through the MitM, the attacker's proxy presents the fraudulent certificate. Because the OneCRL blocklist was never delivered to this client, Firefox validates the chain through the still-trusted eMudhra intermediate and root without warning. The attacker gains full read/write access to the TLS session: credential theft, session hijacking, data manipulation.
Conditions required:
  • Victim runs Firefox < 158.0.1, ESR < 153.5.1, or ESR < 115.43.1
  • Victim's Firefox has DisableRemoteSettingsAndAcceptSecurityConsequences policy enabled
  • Victim navigates to the targeted domain through the MitM
Where this breaks in practice:
  • The DisableRemoteSettingsAndAcceptSecurityConsequences policy is rare — it requires explicit enterprise configuration and has a deliberately alarming name designed to discourage use
  • Estimated <2% of enterprise Firefox installations have this policy active
  • HSTS and preloaded pins for major sites (Google, Microsoft, etc.) prevent interception even with a trusted fraudulent cert for those specific domains
Detection/coverage: TLS-inspecting proxies can detect certificates signed by the eight known-compromised intermediate fingerprints; endpoint telemetry showing unexpected certificate issuers for known domains is a detection signal
03 · Compensating Control

1
MEDIUM 5.0→IGNORE 0.0
SEVERITY REDUCED
Re-enable RemoteSettings in Firefox enterprise policy — If your organization set DisableRemoteSettingsAndAcceptSecurityConsequences to true, removing or reverting this policy is the single most effective mitigation. It allows Firefox to receive OneCRL updates, which have included the eMudhra blocklist entries since October 17. This completely closes CVE-2026-113470 without requiring a binary update. For a MEDIUM verdict there is no noisgate mitigation SLA — go straight to the 365-day remediation window — but this is a one-line GPO/policy change and should be deployed immediately as good hygiene.
2
MEDIUM 5.0→IGNORE 0.0
SEVERITY REDUCED
Update Firefox and Thunderbird to patched versions — Deploy Firefox 158.0.1+, Firefox ESR 153.5.1+ or 115.43.1+, Thunderbird 158.0.1+ or 153.5.1+ across all managed endpoints. The patched binaries include the eMudhra OneCRL entries baked into the binary, protecting even policy-restricted installations. This is the definitive remediation. Per the noisgate remediation SLA for MEDIUM, complete within 365 days — but realistically, fold this into your next scheduled browser patch cycle (likely within 30 days for most orgs).
3
MEDIUM 5.0→LOW 2.5
SEVERITY REDUCED
Deploy TLS inspection rules blocking compromised eMudhra intermediate fingerprints — If you operate a TLS-inspecting proxy (Zscaler, Palo Alto SSL decryption, Squid SSL bump, F5 SSLO), add rules to flag or block certificate chains containing any of the eight known-compromised eMudhra intermediate CA SHA-256 fingerprints. This catches exploitation attempts at the network layer regardless of client patch status. Deploy as defense-in-depth alongside patching within the 365-day remediation window.
4
MEDIUM 5.0→MEDIUM 5.0
Audit all non-browser trust stores for eMudhra root presence — While CVE-2026-113470 is Firefox-specific, the eMudhra compromise affects *any* TLS client trusting emSign ECC Root CA - G3 or the Sectigo AAA cross-sign. Audit Go programs (require ≥1.26.10 or ≥1.27.3), Python environments (certifi ≥2026.10.19), Node.js (≥22.23.4/24.22.1/26.12.1), Java keystores, and appliances with custom trust stores. Use SHA-256 fingerprints from the Endor Labs writeup to scan container images and host filesystems. This addresses the broader eMudhra exposure tracked under separate CVEs.
What doesn't work
  • OCSP/CRL checking alone — eMudhra may have revoked the intermediates via OCSP, but Firefox's OneCRL mechanism exists precisely because OCSP is unreliable (soft-fail default, responder outages, privacy concerns). Most non-browser TLS clients skip OCSP entirely. Do not rely on revocation checking as your primary defense.
  • Removing eMudhra from the OS certificate store — Firefox uses its own NSS certificate store, not the operating system's trust store. Removing emSign ECC Root CA - G3 from the Windows/macOS/Linux system store does not affect Firefox. You must update the Firefox binary or re-enable RemoteSettings.
  • HTTP Public Key Pinning (HPKP) — Deprecated and removed from all major browsers years ago. While HSTS preload protects navigation to major domains, it does not prevent interception with a CA-signed fraudulent certificate for non-preloaded domains.
04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitationNone confirmed. CISA SSVC assessment records exploitation as 'none'. eMudhra states no evidence of key recovery or exploitation before disclosure. No entry in the CISA KEV catalog as of 2026-10-23.
Proof-of-concept availabilityKey recovery is trivial and public. Researcher 'Wayne' demonstrated possession by signing attestations with all eight keys. Multiple parties have independently recovered the keys since October 17. No weaponized browser-targeting PoC published on pocindex.io, GitHub, or ExploitDB. The 'PoC' is the key material itself — generating a fraudulent cert requires only standard openssl commands.
EPSS score0.00342 (~30th percentile). Very low exploitation probability, consistent with the MitM + policy-disabled prerequisites narrowing the attack surface.
KEV statusNot listed in the CISA Known Exploited Vulnerabilities catalog.
CVSS vector interpretationCVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N → 5.4 MEDIUM. AC:L is arguably generous — MitM positioning would typically warrant AC:H (dropping the score to ~4.2). C:L and I:L undercount impact for the affected user (full session interception), but reflect the narrow population.
Affected version rangesFirefox < 158.0.1, Firefox ESR < 153.5.1, Firefox ESR < 115.43.1, Thunderbird < 158.0.1, Thunderbird < 153.5.1. Exploitable only when DisableRemoteSettingsAndAcceptSecurityConsequences policy is active — all other users received the OneCRL block on Oct 17 via RemoteSettings.
Fixed versionsFirefox 158.0.1, Firefox 158.0.2 (Android blocklist application fix), Firefox ESR 153.5.1, Firefox ESR 115.43.1, Thunderbird 158.0.1, Thunderbird 153.5.1. Distro packages: Debian/Ubuntu firefox-esr, Fedora firefox, Arch firefox — check repos for equivalent point releases.
Compromised certificatesEight eMudhra intermediates: EM DV TLS CA - G3B/G3C, EM OV TLS CA - G3B/G3C, EM EV TLS CA - G3B/G3C (6× TLS) and EM OV CS CA - G3B/G3C (2× code-signing). All chain to emSign ECC Root CA - G3 and cross-signed under Sectigo AAA Certificate Services.
Disclosure timelineOct 17 18:05 UTC — reported to Chrome Root Program. Oct 17 19:45 — Chrome CRLSet block (100 min). Oct 17 22:59 — Firefox OneCRL via RemoteSettings. Oct 19 — Apple blocks. Oct 20 — Microsoft blocks; MFSA 2026-111 published; Firefox 158.0.1 / ESR releases. Oct 21 — Firefox 158.0.2 (Android fix).
ReporterResearcher credited as Wayne — discovered the weak keys while auditing the Common CA Database (CCADB). Submitted signed attestations proving key possession to all major browser root programs and eMudhra simultaneously. Disclosure site: emudhra.we-have-a-problem.com.

Sources.

  1. Mozilla Security Advisory MFSA 2026-111
  2. Mozilla Security Blog — Protecting Firefox users following eMudhra compromise
  3. GitHub Advisory Database — GHSA-vr39-qqr3-x9v4
  4. Endor Labs — eMudhra: The Trust Stores You Didn't Patch
  5. Rescana — eMudhra CA Key Compromise Analysis
  6. Bugzilla — eMudhra Private Key Compromise of Intermediate Certificates
  7. eMudhra Disclosure Site
  8. CVE-2026-113470 Detail — cvefeed.io
05 · The Call

Final Verdict
= UNCHANGED to MEDIUM (5.0/10)

Why this verdict

  • MitM prerequisite adds major friction. Exploiting CVE-2026-113470 requires the attacker to already hold a network position between the victim and target server — ARP spoofing, rogue AP, DNS hijack, or compromised infrastructure. This is not a remote click-to-own vulnerability. Enterprise controls (802.1X, DNSSEC, network segmentation, WIDS) substantially impede this step. The CVSS vector's AC:L is arguably too generous; AC:H would be more accurate for MitM-dependent chains.
  • Affected population is extremely narrow. Only Firefox/Thunderbird installations with the DisableRemoteSettingsAndAcceptSecurityConsequences enterprise policy active are exposed to this CVE. This policy has an intentionally alarming name and requires deliberate administrative action. Estimated <2% of the enterprise Firefox installed base. The remaining 98%+ received the OneCRL update automatically on October 17, three full days before the binary fix.
  • No active exploitation despite public key material. The eight compromised private keys have been independently recovered by multiple researchers and are effectively public. Despite this, no fraudulent certificates have been observed in CT logs, no exploitation reported by any monitoring service, and CISA SSVC records exploitation as 'none'. EPSS at 0.00342 confirms low exploitation probability.
  • Role multiplier: Firefox is an endpoint client application, not infrastructure. Firefox does not occupy a high-value deployment role — it is not an identity provider, certificate authority, hypervisor, network edge appliance, domain controller, or CI/CD component. The blast radius of a successful exploit is one user's browsing session on one host: potential credential theft or data manipulation for that individual. This is host-level impact, not fleet/domain/supply-chain scale. No high-value role floor applies to this component.
  • Underlying CA compromise is severe but scoped to different tracking IDs. The eMudhra key compromise itself is a serious PKI trust incident affecting the entire web ecosystem, but CVE-2026-113470 specifically covers Firefox's blocklist delivery gap for the policy-restricted minority. Broader non-browser exposure (Go crypto/x509, Python certifi, Node.js, Java trust stores, appliances) is tracked under CVE-2026-111943 and vendor-specific advisories — those deserve separate assessment.

Why not higher?

A HIGH rating would require either a broader affected population or removal of the MitM prerequisite. The underlying eMudhra compromise IS high-severity for the web PKI ecosystem, but this CVE covers a narrow delivery-mechanism gap affecting only Firefox/Thunderbird installations that deliberately opted out of security updates via enterprise policy. The compounding of MitM requirement + policy-disabled prerequisite narrows the realistic attack surface to a sliver. No exploitation evidence exists to justify elevation.

Why not lower?

A LOW rating would undercount the risk for the affected pocket. For organizations that *did* disable RemoteSettings — and they exist, often in air-gapped or high-security environments — the exploitation path is straightforward once MitM is achieved: keys are public, cert generation is trivial, and the browser trusts the fraudulent chain with zero warnings. Full TLS session interception (credentials, tokens, data) is the outcome. The CVSS C:L/I:L actually undercounts per-session impact. The 5.0 score appropriately weights this real-but-narrow risk.

06 · Verification

Crowdsourced verification payload.

Run on each target Linux/macOS host where Firefox or Thunderbird is installed. Execute as any unprivileged user with read access to the Firefox binary and policy directories. Example: chmod +x check_cve_2026_113470.sh && ./check_cve_2026_113470.sh. Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-113470 — Firefox/Thunderbird eMudhra OneCRL blocklist gap check
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -uo pipefail

RESULT="UNKNOWN"
FF_BIN=""
PRODUCT=""

# Locate Firefox or Thunderbird
for candidate in firefox firefox-esr thunderbird; do
    if command -v "$candidate" &>/dev/null; then
        FF_BIN="$candidate"
        case "$candidate" in
            thunderbird)  PRODUCT="Thunderbird" ;;
            firefox-esr)  PRODUCT="Firefox ESR" ;;
            *)            PRODUCT="Firefox" ;;
        esac
        break
    fi
done

if [[ -z "$FF_BIN" ]]; then
    echo "UNKNOWN - Neither Firefox nor Thunderbird found in PATH"
    exit 2
fi

# Extract version string
VERSION_LINE=$($FF_BIN --version 2>/dev/null || true)
FF_VERSION=$(echo "$VERSION_LINE" | grep -oP '[0-9]+\.[0-9]+\.?[0-9]*' | head -1)

if [[ -z "$FF_VERSION" ]]; then
    echo "UNKNOWN - Could not parse version from: $VERSION_LINE"
    exit 2
fi

echo "[*] Detected: $PRODUCT $FF_VERSION ($FF_BIN)"

# Version comparison: returns 0 if $1 >= $2
version_ge() {
    [[ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -1)" == "$2" ]]
}

# Determine ESR status
IS_ESR=false
[[ "$FF_BIN" == *"esr"* ]] && IS_ESR=true
$FF_BIN --version 2>/dev/null | grep -qi "esr" && IS_ESR=true

MAJOR=$(echo "$FF_VERSION" | cut -d. -f1)

# Check against fixed versions
if [[ "$PRODUCT" == "Thunderbird" ]]; then
    if [[ "$MAJOR" -ge 158 ]] && version_ge "$FF_VERSION" "158.0.1"; then
        RESULT="PATCHED"
    elif [[ "$MAJOR" -eq 153 ]] && version_ge "$FF_VERSION" "153.5.1"; then
        RESULT="PATCHED"
    else
        RESULT="VULNERABLE"
    fi
elif $IS_ESR; then
    if [[ "$MAJOR" -eq 115 ]]; then
        version_ge "$FF_VERSION" "115.43.1" && RESULT="PATCHED" || RESULT="VULNERABLE"
    elif [[ "$MAJOR" -eq 153 ]]; then
        version_ge "$FF_VERSION" "153.5.1" && RESULT="PATCHED" || RESULT="VULNERABLE"
    elif [[ "$MAJOR" -ge 158 ]]; then
        RESULT="PATCHED"
    else
        RESULT="VULNERABLE"
    fi
else
    version_ge "$FF_VERSION" "158.0.1" && RESULT="PATCHED" || RESULT="VULNERABLE"
fi

# Check if RemoteSettings is disabled by enterprise policy
RS_DISABLED=false
POLICY_DIRS=(
    "/etc/firefox/policies"
    "/usr/lib/firefox/distribution"
    "/usr/lib64/firefox/distribution"
    "/snap/firefox/current/distribution"
    "/etc/thunderbird/policies"
    "/usr/lib/thunderbird/distribution"
)
for dir in "${POLICY_DIRS[@]}"; do
    pf="$dir/policies.json"
    if [[ -f "$pf" ]] && grep -qi 'DisableRemoteSettingsAndAcceptSecurityConsequences' "$pf" 2>/dev/null; then
        RS_DISABLED=true
        echo "[!] WARNING: RemoteSettings disabled by policy in $pf"
        break
    fi
done

# Final output
if [[ "$RESULT" == "PATCHED" ]]; then
    echo "PATCHED - $PRODUCT $FF_VERSION includes baked-in eMudhra OneCRL blocklist (CVE-2026-113470)"
    exit 0
elif [[ "$RESULT" == "VULNERABLE" ]]; then
    if $RS_DISABLED; then
        echo "VULNERABLE - $PRODUCT $FF_VERSION unpatched AND RemoteSettings disabled — FULLY EXPOSED to CVE-2026-113470"
    else
        echo "VULNERABLE - $PRODUCT $FF_VERSION binary unpatched, but RemoteSettings likely delivered OneCRL on Oct 17 (reduced risk unless RS is blocked by network)"
    fi
    exit 1
else
    echo "UNKNOWN - Could not determine status for $PRODUCT $FF_VERSION"
    exit 2
fi