Remediating the eMudhra Certificate Authority Compromise

On Oct 20, 2026, it was publicly disclosed that several eMudhra certificate authority certificates were compromised. ‼️

There was a bug in eMudhra's key generation ceremony that caused them to be generated with private keys like the literal number 4 and other small numbers that could be cracked in milliseconds, which researchers quickly figured out.

(credit: https://redd.it/1xdcjgl)

The impact

Anyone can trivially impersonate hosts to clients that trust the eMudhra CAs, and because these CAs chain to root CAs trusted by nearly all software on earth, pretty much any web host can be impersonated.

• If you're on a shared Wi-Fi network, your network administrator can MITM your traffic and impersonate Gmail or Apple or your bank.
• Even if you own the hardware and software stack on your LAN, your traffic still gotta leave your LAN and traverse the internet, where your ISP or someone (hello NSA 👀) tapping into the copper or fiber lines running across the world can intercept and modify your traffic, impersonating whomever they want.

A lot of layers to fix

The problem is manifold: different software at different levels often bundle their own trust stores, so while your OS might have gotten an emergency patch that distrusts the certs at the OS level, and your browser might've gotten an emergency patch, other software running on your patched OS can still be vulnerable without an update for that specifically.

What about revocation?

What about revocation protocols and online CRLs?

Unfortunately, revocation is broken, and most software up and down the stack doesn't consult or honor online CRLs in their cert validation path — I'm talking your OS, cURL, the default crypto / cert libraries in Go, Python, Rust, Node, etc.

CRLs and OCSP are unfortunately only really used by web browsers, and even then support is optional.

Patching the world

Software projects and organizations have been rushing to patch the vuln by updating their trust stores explicitly to blocklist the compromised certs, but not every vendor is so fast on the uptake.

But there are billions of devices running outdated software that don't get updates anymore, or that do but whose vendors don't do keep up with the bleeding edge and put out weekly updates to keep up with the deluge of vulnerabilities that keep dropping in the new AI era, and they are truly hosed — your smart fridge, internet-connected car, or smart mattress (lol) are wide open, unfortunately.

Patching it ourselves

For everything not receiving emergency vendor updates, we gotta patch it ourselves. Let's walk through an example: patching Unifi devices.

As of Oct 23, 2026, Ubiquiti has not released any mainline updates patching this on Unifi OS, Unifi Core, or the Unifi Network application, etc.

The recommended fix in the advisory is to entirely distrust the roots which the eMudhra certs chain up to: emSign ECC Root CA - G3, AAA Certificate Services

• Merely removing the compromised intermediates from the trust store is insufficient, as a server can always present the intermediate along with whatever leaf certificate they want to sign with it, and since the intermediate chains up to a trusted root, the leaf will be accepted.
• Note this does have a compatibility risk for legitimate certs that chain up only to the AAA root through other uncompromised intermediates.

Tl;dr: on a Unifi device, there are several layers that need to be patched:

Component	Change	Coverage
OS trust	Deselect affected roots in /etc/ca-certificates.conf → run update-ca-certificates to update bundle + hashed dir.	Clients using Debian’s store, e.g., installed Python certifi, Go clients using system root pool.
UniFi Core	Extract Node bundled trust store certs → Remove affected roots → Update unifi-core launch env to select patched bundle.	Default Node TLS clients, while preserving Node-specific bundled roots.
UniFi Network	Extract embedded CA roots from unifi executable → Build filtered JKS → Update launch env (UNIFI_NATIVE_OPTS) override JKS.	Java default trust-manager paths that honor the documented GraalVM override.

The specific steps are quite complicated and may change depending on what version of Unifi OS / Core / Network your device is running, so rather than providing a deterministic script, I recommend you:

1. Point your coding agent at this article and have it analyze your specific UniFi environment and what components — potentially others beyond these which were relevant to my UniFi deployment — needs patching and what that would entail.

   

2. Back up your device — don't skip this step!

3. Make the changes.

4. Restart device, verify connectivity, application health checks, logs

5. Verify affected CAs no longer trusted in each affected component.

6. Rest easy until the next 0-day drops in a week! 🙂