Mozilla has issued an unusual pair of Firefox security updates after private keys tied to eight eMudhra intermediate certificates were reported compromised. Firefox 158.0.1 for desktop and Firefox 158.0.2 for Android contain protections intended to block certificates issued through the affected chain, including cases where Firefox’s normal remote blocklist delivery is disabled or unavailable.
The practical advice is straightforward: let Firefox update, restart it, and confirm the installed version. Most people do not need to delete certificates or change browser settings. Organizations that pin versions or block Mozilla’s Remote Settings service should treat the release as a priority deployment because the packaged update is the fallback protection for those environments.
Firefox certificate update at a glance
- Incident reported to Mozilla: October 17, 2026, at 20:06 UTC.
- Affected material: private keys associated with eight eMudhra intermediate certificates.
- Immediate response: Mozilla added the affected certificates to OneCRL and completed distribution by 22:59 UTC, less than three hours after receiving the report.
- Desktop release: Firefox 158.0.1, issued October 20.
- Android follow-up: Firefox 158.0.2, issued October 21 to make sure the bundled OneCRL blocklist is installed at startup.
- ESR releases: Firefox ESR 115.43.1 and Firefox ESR 153.5.1 carry the response for supported enterprise branches.
- Security classification: Mozilla rates CVE-2026-113470 as high impact.
A secure-web certificate helps a browser establish that it is talking to the intended site and that the connection is encrypted. An intermediate certificate sits between a trusted root authority and the certificates presented by websites. If an intermediate private key is compromised, an attacker may be able to issue a fraudulent certificate that appears to chain back to a trusted authority.
What happened to the eMudhra certificates
Mozilla says it received the compromise report on Saturday, October 17. The report involved private keys associated with eight eMudhra intermediate certificates. Possession of those keys could allow an attacker to create certificates for domains the attacker does not control.
A fraudulent certificate is not automatically enough to read someone’s browsing traffic. The attacker would also need a way to intercept or redirect the connection—for example through a compromised network, malicious routing, hostile proxy or another man-in-the-middle position. In that situation, the certificate could help the attacker impersonate a legitimate website and potentially read or modify traffic that the victim believed was protected.
This distinction matters. Mozilla did not say that every Firefox user was attacked, nor that every certificate issued by eMudhra was fraudulent. The response blocks the affected certificate paths so they cannot be used to establish trust in Firefox.
Why compromised certificates matter
The padlock in a browser address bar signals that the current connection is encrypted and that the site presented a certificate the browser accepted. It is not a guarantee that the organization behind the page is honest, and it depends on the integrity of the certificate chain.
A root certificate authority can delegate certificate issuance to intermediate authorities. Those intermediates sign website certificates. Browsers maintain trust stores and revocation mechanisms so a certificate path can be rejected when a key is lost, misused or otherwise unsafe. Blocking a compromised intermediate is therefore a way to prevent every certificate relying on that path from being accepted, without waiting for individual websites to change.
For everyday users, the visible effect should be minimal. A correctly updated browser silently refuses the affected chain. If a site still depends on one of the blocked certificates, Firefox may show a secure-connection error until the site operator replaces the certificate chain.
How Mozilla blocked the certificates
Mozilla first used OneCRL, its remotely delivered list of revoked certificates. The Firefox Security Team says the block reached standard Firefox configurations less than three hours after the report. OneCRL is distributed through Mozilla’s Remote Settings system, allowing urgent security-state changes between normal browser releases.
That fast response does not cover every configuration equally. An enterprise policy, network restriction or custom preference can prevent Remote Settings from arriving. Firefox 158.0.1 therefore includes the updated OneCRL data inside the application package, so the browser can enforce the block even when remote delivery is unavailable.
Mozilla also updated its Network Security Services trust store to NSS 3.131.1 and removed the root certificate that signed the affected intermediates. That broader step helps other applications based on Mozilla’s trust store, including products that do not receive Firefox’s OneCRL updates.
Which Firefox versions users should have
- Firefox desktop release channel: version 158.0.1 or later.
- Firefox for Android: version 158.0.2 or later.
- Firefox ESR 153 branch: version 153.5.1 or later.
- Firefox ESR 115 branch: version 115.43.1 or later.
Version numbers can move forward quickly. If Firefox offers a version newer than the numbers above, install the newer supported release rather than attempting to downgrade. A newer version should include the earlier security response unless Mozilla publishes a specific exception.
The desktop advisory for Firefox 158.0.1 also includes a separate high-impact SVG boundary-condition fix and several stability corrections. Release notes list fixes for unexpected scrolling while selecting text, a Windows print-to-PDF crash involving assistive technology, incorrect monitor selection on Linux, a built-in VPN startup problem and macOS drag-and-drop failures.
Why Android needed a second update
Mozilla initially released Firefox 158.0.1 for desktop and Android with the bundled blocklist. On October 21, it added Firefox for Android 158.0.2 after finding that some Android clients were not applying the bundled OneCRL changes immediately at startup.
The 158.0.2 release narrows that exposure window by ensuring the pre-distributed blocklist is installed as Firefox starts. Android users should not assume that having 158.0.1 is the end of the task; the relevant Android target is 158.0.2 or any newer release offered through the device’s app store.
How to check and update Firefox
- On desktop, open the Firefox menu and choose Help, then About Firefox. On macOS, the About Firefox command is also available from the Firefox menu in the menu bar.
- Allow Firefox to check for and download the update. When prompted, restart the browser so the new version is actually running.
- Open About Firefox again and confirm version 158.0.1 or later.
- On Android, open the Google Play Store, search for Firefox and install any available update. Then open Firefox, go to Settings and About Firefox, and confirm version 158.0.2 or later.
- If Firefox came from the Microsoft Store or a Linux distribution repository, use that store or package manager because it may control the update channel.
Firefox normally updates automatically, but an update may not finish until the browser restarts. A managed work or school device may also be pinned to an administrator-approved version. If the About screen says updates are controlled by your organization, contact the administrator instead of trying to bypass policy.
What managed and offline devices need
The highest-priority cases are systems that do not receive Mozilla Remote Settings reliably. That can include locked-down enterprise images, offline workstations, filtered networks, lab machines and devices that remain open for long periods without restarting.
- Confirm the installed Firefox or ESR version through inventory rather than assuming automatic updates completed.
- Deploy the applicable 158.0.1, 153.5.1 or 115.43.1 package—or a newer supported release—through the organization’s normal software-management system.
- Restart Firefox processes after deployment so the updated application and packaged blocklist are active.
- Do not re-enable a blocked certificate chain merely to suppress a site error. Replace the server certificate chain or work with the site operator.
- Review proxy, TLS-inspection and private-certificate deployments before changing trust settings; enterprise certificates are a separate configuration from the compromised public intermediates.
Administrators using a custom certificate authority for internal sites should test those sites after updating. An internal certificate error does not prove the public eMudhra incident caused it, and weakening certificate validation can create a larger security problem than the original outage.
What this update does not mean
The release is not evidence that Firefox’s encryption was broken. It is a trust-management response to compromised certificate keys. Mozilla’s rapid OneCRL distribution reduced exposure for standard configurations, while the packaged update covers systems that might miss that remote change.
The incident also does not require most people to reset every password. If you encountered a suspicious certificate warning, used an untrusted network during the affected period or believe you entered credentials into an impersonated site, update first, move to a known-trusted connection and change the affected password from a clean device. Otherwise, installing the browser update is the proportionate response.
Do not click through a certificate warning because a site appears familiar. Check the exact domain, reopen it from a trusted bookmark and let the site operator resolve the certificate problem. Certificate warnings are designed to stop the connection before credentials or other sensitive data are exposed.
Practical account security steps
- Keep Firefox, Android and the operating system on supported releases.
- Use unique passwords and a reputable password manager.
- Enable phishing-resistant multifactor authentication or passkeys when an important account supports them.
- Treat unexpected login prompts and certificate warnings as separate reasons to stop and verify the site.
- Avoid changing advanced certificate settings unless an administrator or documented support process requires it.
- On shared or managed devices, report warnings to IT instead of installing certificates supplied by an unknown website.
Is a hardware security key relevant here?
A hardware security key cannot fix a compromised certificate authority and does not replace the Firefox update. It can, however, add phishing-resistant authentication to supported accounts. Even if an attacker learns a password, a properly configured FIDO security key can make account takeover harder because authentication is bound to the legitimate website origin.
A verified option is the Yubico Security Key C NFC on Amazon. It uses USB-C or NFC and supports FIDO-based authentication, but compatibility depends on the account, device and sign-in method. Confirm those details and the current seller before ordering.
Affiliate disclosure: ReaderSpice may earn a commission from qualifying Amazon purchases made through the link above, at no additional cost to you.
Bottom line
Firefox users should update rather than panic. Mozilla says standard configurations received the OneCRL block within hours, and the browser releases add a packaged fallback for clients that missed remote delivery. Desktop users need Firefox 158.0.1 or later, while Android users should be on 158.0.2 or later.
The larger lesson is that HTTPS protection depends on more than encryption alone. Browsers also need a trusted certificate chain and a fast way to revoke unsafe intermediates. Keeping the browser current is what turns Mozilla’s certificate response into protection on the device in front of you.
Sources
Mozilla MFSA 2026-111: Security vulnerabilities fixed in Firefox 158.0.1
Firefox for Android 158.0.2 release notes
Mozilla MFSA 2026-116: Security vulnerabilities fixed in Firefox for Android 158.0.2
Mozilla Support: Update Firefox to the latest release
Firefox Source Docs: Remote Settings and the OneCRL security-state collection
