eMudhra CA Compromise (CVE-2026-111943): 10 Fixes for Developers

Updated 23 October 2026. Browsers blocked eight compromised eMudhra intermediate certificates between 17 and 22 October, and Linux distributions, Go, Node.js, Python and Java have now shipped trust store fixes; this checklist covers what developers and site owners still need to do.

The eMudhra CA compromise is a certificate authority incident in which the private keys of eight eMudhra intermediate CA certificates were generated so weakly that anyone could recover them from the public certificates. With one of those keys, an attacker could issue a certificate for any website, and any client that still trusts the intermediates would accept it. Chrome and Firefox blocked them on 17 October 2026, Microsoft platforms on 20 October and Apple products on 22 October, so up-to-date browsers are protected.

The remaining risk sits outside the browser: curl, Python, Node.js, Go, Java and container images trust a CA bundle on disk and rarely check revocation. Update the OS ca-certificates package and each runtime to the versions below, rebuild images and Go binaries, then confirm with the public test hosts. If your own site's certificate chains to emSign ECC Root CA - G3, replace it before Chrome removes that root on 27 October 2026.

Related: Deno Deploy Shutdown: Migrate to Cloudflare Workers in 8 Steps

eMudhra CA compromise at a glance

What happened to eMudhra's certificates?

eMudhra is an Indian certificate authority. On 30 April 2025 it created eight intermediate CAs under its emSign ECC root, which Sectigo cross-signed under its AAA Certificate Services root in May 2025. eMudhra says a wrap and unwrap step in that key ceremony produced a second, weak set of keys, and the weak keys were the ones published. Scott Helme found that each private key was a single byte, such as 4, 56 or 115, and recovered all eight in under a second.

• 17 October: a researcher reports the keys to the browser root programs. Chrome pushes a CRLSet block at 19:45 UTC; Mozilla's OneCRL block reaches Firefox users by 22:59 UTC.
• 18 October: eMudhra revokes all eight intermediates.
• 19 October: Android gets an equivalent block through Google Play services.
• 20 October: NSS 3.131.1, Firefox 158.0.1, Go 1.27.3 and Ubuntu's fixed packages ship; Microsoft platforms start blocking.
• 21 October: Node.js, Python and OpenJDK release fixes; Red Hat publishes RHSB-2026-012.
• 22 October: Apple blocks the certificates, Docker Desktop 4.96.2 ships, and eMudhra says it will leave the global SSL/TLS business.
• 27 October: Chrome removes emSign ECC Root CA - G3 from its root store.

Who is at risk from the eMudhra intermediates?

Browsers are in good shape. Chrome, Firefox and Safari require Certificate Transparency, Google says no certificates from these intermediates were logged before the blocks, and the researchers' tracker says CT-enforcing browsers could not have been attacked. The exposure is in software that trusts a plain CA bundle:

• Command-line tools and SDKs. In Helme's test, unpatched curl, Python and Node.js accepted a forged certificate for api.stripe.com.
• CI/CD pipelines, curl | sh installers and server-to-server API calls that carry cloud keys and other secrets.
• Container images built before the fixes.
• IoT, embedded and OT devices with frozen trust stores, which Helme warns will trust the intermediates until they expire in July 2039.
• Windows code signing, since two of the eight were code-signing CAs and Helme notes that Windows trusts the eMudhra code-signing root directly.

Which versions fix the eMudhra certificates?

The tracker also lists Electron, Homebrew and rustup fixes, and pending ones such as Composer's ca-bundle for PHP.

The 10-step eMudhra fix checklist

1. Update the operating system trust store

Most Linux tools read the system bundle, so start there. On Debian and Ubuntu:

sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg -s ca-certificates | grep Version

On Alpine, run apk upgrade ca-certificates; on Fedora, sudo dnf upgrade ca-certificates. Red Hat had not published RHEL errata at its 22 October update; check rpm -q ca-certificates, and if you cannot wait, its bulletin links a procedure that blocks the two roots the intermediates chain to. The researchers say manual distrust is for expert users, so test it on one machine first.

2. Update Python's CA bundle in every environment

pip and many Python HTTP libraries, including requests, use certifi's bundle rather than the system store. The Python team asks you to upgrade pip and uv in every virtual environment, starting with a hash-pinned pip so the download cannot be tampered with:

python -m pip install "pip @ https://files.pythonhosted.org/packages/3f/06/3e4420302363fbb71be3c7f35ce042f54bfca330e3e66b3a2e3c4cca579f/pip-26.2.2-py3-none-any.whl#sha256=fd7f4dfa8190e014013b9f08f3e973f4e4c26ffd179a204895533a7254813a70"
python -m pip install --upgrade certifi uv
python -c "import certifi; print(certifi.__version__)"

Expect 2026.10.19 or later. The Python 3.15.1, 3.14.9 and 3.13.17 installers bundle the fixed pip; for a python.org install on macOS, use the framework paths in the Python release post.

3. Move Node.js to 26.12.1, 24.22.1 or 22.23.4

Node.js ships its own copy of Mozilla's root list inside the binary, so an OS update does not change what a default Node process trusts. The 21 October security releases updated those roots to NSS 3.131.1, and they also fixed the Brotli bug in our Node.js October security release guide. Check node -v on servers and in CI images.

4. Rebuild Go programs with Go 1.27.3 or 1.26.10

Go 1.27.3 and 1.26.10, released on 20 October, make crypto/x509 filter out chains that contain the blocked intermediates. The fix is compiled into each program, so rebuild and redeploy every Go service and tool you build. To see which Go version built a binary:

go version ./bin/your-service

5. Patch Java runtimes

The OpenJDK advisory for CVE-2026-91403 lists 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.32.1, 8u504 and earlier as affected. A JDK packaged by Debian, Ubuntu, RHEL, Fedora, Arch, Gentoo or Oracle Linux uses the OS certificates, so step 1 covers it. Standalone JDKs, and the FreeBSD and Homebrew packages, must be updated directly. Until then, OpenJDK suggests replacing the JDK's lib/security/blocked.certs with the file it publishes, or turning on revocation checks:

java -Dcom.sun.net.ssl.checkRevocation=true -Dcom.sun.security.enableCRLDP=true -jar app.jar

6. Rebuild container images without the cache

A container keeps the CA bundle it was built with. The Python security team recommends rebuilding images with layer caching disabled:

docker build --pull --no-cache -t your-app:latest .

The base image must already contain the fixed package, so check its date or add an apt-get install --only-upgrade ca-certificates step to the Dockerfile. Then redeploy, because running containers do not change.

7. Update desktop tools, including macOS command-line tools

Install Docker Desktop 4.96.2 or later; Docker says it removes trust in the compromised intermediates for the Docker CLI and daemon, and is rolling the fix out across components in batches. On macOS, Apple blocks the intermediates, but the tracker notes that the built-in curl, git, python3, perl, ruby and openssl read /etc/ssl/cert.pem, which had not been updated when it last checked; it gives a command that removes the two affected roots after taking a backup. For Homebrew tools, run brew upgrade ca-certificates.

8. Test each client against the eMudhra test hosts

The researchers run test sites signed by a compromised intermediate, including one chain through the Sectigo cross-sign. After you patch, these should fail with a certificate error:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
python -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/')"

A normal response, or no error from the Python line, means that client still trusts the compromised intermediates. Run the tests on servers, CI runners and inside containers, not only on your laptop. Two more hosts with noct in the name show whether a client also accepts certificates never logged to Certificate Transparency.

9. Check whether your own site uses an eMudhra certificate

Run this against each public hostname and read the issuer lines:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:"

If the chain ends at emSign ECC Root CA - G3, Google says you must get a new certificate from another hierarchy in the Chrome Root Store now. Chrome stops trusting that root on Tuesday morning, 27 October 2026, Pacific time, and sooner in Canary and Beta. eMudhra says this affects one customer ecosystem in the United States, which it is moving to replacement certificates.

10. Plan for clients you cannot patch

List devices with frozen trust stores, such as routers, printers and OT controllers. Keep them off untrusted networks, route their traffic through a proxy you control, or plan replacement. Keep Windows machines updated too, because of the two code-signing intermediates. Our web application security guide covers the wider habits.

What if my website uses an eMudhra certificate?

Most eMudhra customers do not need an emergency swap: eMudhra says the revoked intermediates never issued a certificate, and most of its TLS certificates chain to other hierarchies. Two changes still matter. On 22 October eMudhra said it will exit the global SSL/TLS certificate business, keep its G1 RSA roots running during the transition and arrange free replacement certificates from partners. And Google says it is reviewing whether eMudhra's remaining CA certificates should stay in the Chrome Root Store. If you buy certificates from eMudhra, plan a move to another CA now rather than under a deadline, and add certificate checks to your routine, as in our website launch checklist.

This landed in the same week as PHP2Shell and the Node.js security release. If that pace is hard to keep up with, our comparison of VPS, serverless and managed hosting shows who patches what. For a second pair of eyes on which servers, images and pipelines still trust the old bundle, our web development team can review it with you, or contact us with your stack details. Keeping runbooks in a knowledge base assistant also makes the next incident faster to handle.

eMudhra CA compromise FAQ

Is my browser safe from the eMudhra certificates?

Yes, if it is up to date. Chrome and Firefox blocked the eight intermediates on 17 October 2026 through CRLSets and OneCRL, which apply without a browser update, and Microsoft and Apple followed on 20 and 22 October. These browsers also enforce Certificate Transparency, and Google says no certificates from these CAs were logged before the blocks. The open risk is in command-line tools, servers and devices.

What is CVE-2026-111943?

CVE-2026-111943 is the identifier the Go team assigned to its fix, which makes crypto/x509 reject chains containing the compromised eMudhra intermediates. Red Hat's bulletin uses it as the headline ID for the whole incident. Other projects track the same certificates under their own numbers, such as CVE-2026-91403 for OpenJDK and CVE-2026-114406 for RHEL's ca-certificates package.

How do I check if my server still trusts the compromised intermediates?

Run curl against https://dv-g3b-emudhra.we-have-a-problem.com/ and https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ from the server, a CI runner and each container image. A certificate error means the client no longer trusts the intermediates. A normal response means it still does, so update the system ca-certificates package and the runtime, then test again, including from Python or Node.js.

When does Chrome remove the emSign ECC Root CA - G3?

Google says the removal reaches every device that relies on the Chrome Root Store on Tuesday morning, 27 October 2026, Pacific time, and arrives sooner in Chrome Canary and Beta. Sites whose certificates chain to that root will then fail in Chrome, so Google tells those operators to install a certificate from another hierarchy immediately.

Do I need to do anything if I never bought an eMudhra certificate?

Yes, on the client side. The risk is about which certificates your software trusts, not which certificate your site uses. Any server, laptop or container with an old CA bundle would accept a forged certificate from these intermediates, for example in a man-in-the-middle attack on an API call or package download. Updating trust stores, runtimes and images closes that gap.

Why is eMudhra leaving the SSL/TLS certificate business?

In its 22 October 2026 announcement, eMudhra said global SSL/TLS is about 1% of its revenue, that free certificates from large providers had reduced its potential return, and that public attention to the incident was out of proportion to its size. Its digital signature, eSign and enterprise PKI services continue, and affected TLS customers get free replacements from partners.

Sources

• eMudhra compromise tracker and test hosts
• Google Chrome and Android security post (20 October)
• Mozilla Security Blog post (20 October)
• Scott Helme: Eight Bits of Trust
• Red Hat bulletin RHSB-2026-012
• Go 1.27.3 and 1.26.10 announcement
• Node.js 24.22.1 release notes
• Node.js 26.12.1 release notes
• Node.js 22.23.4 release notes
• Python 3.15.1, 3.14.9 and 3.13.17 release post
• Python Discourse announcement for Python users
• certifi 2026.10.19 release
• OpenJDK advisory 2026/10/21
• Ubuntu ca-certificates bug 2171507
• Debian security tracker: ca-certificates
• Docker Desktop release notes
• eMudhra incident statement and updates
• eMudhra statement on the distrust (21 October)
• eMudhra exit from global SSL/TLS (22 October)