eMudhra CA compromise: eight private keys, and one of them is 4

‍TL;DR

eMudhra, a certificate authority that all the major browsers trust, generated the private keys for eight of its signing certificates in a way that meant one of them is just the number 4, about as easy to guess as a key can be. A properly generated key takes about 10^115 guesses to find. These took at most 256, enough for anyone who can intercept your traffic to impersonate any website.

• Who is affected: browsers have already blocked the certificates. Servers, CI pipelines, Docker images and command-line tools such as curl and git may still trust them, because they never check whether a certificate has been revoked.
• What to do: update your CA bundle and rebuild your images. The steps are below.
• How Aikido helps: Aikido flags container images that still carry the affected certificate bundles as Critical or High issues.

Who is affected

Most browser users are covered. Firefox and Chrome have blocked the certificates since October 17, Apple devices since October 19 and Microsoft platforms since October 20, using the revocation lists their vendors push to users.

The eight affected certificates are intermediate CAs, which are signing certificates that chain up to a trusted root. Whoever holds an intermediate's private key can sign a valid certificate for any domain. These eight chain up to emSign ECC Root CA - G3, which Mozilla has removed from its trust store and which Chrome expects to follow on October 27.

The exposure is in software that does its own certificate checking:

• Command-line tools. On macOS, the built-in curl, git, python3, perl, ruby and openssl verify against /etc/ssl/cert.pem without checking revocation, and that file does not update automatically. The content of that file and subsequently your Linux tools depend on the ca-certificates package of your distribution.
• Containers and CI. An image carries the CA bundle it was built with. Many images still ship the old one.
• Language runtimes. Go, Java, Node.js, Python's certifi, Rust's webpki-roots and others bundle their own roots and each needed its own release.
• IoT: Internet of Things devices ship CA certificates with their firmware, and due to the difficulty of updating, will likely remain vulnerable for years.
• Code signing. Six of the eight intermediates were for TLS and two were Microsoft-trusted code-signing CAs, so an attacker could also sign malware under any publisher name. Microsoft has blocked them since October 20.

Using a forged certificate still takes a position on the network path, such as a hostile Wi-Fi network or a compromised router. The incident site also reports that the eight intermediates didn't appear in certificate transparency logs before the block, so clients that enforce transparency (Firefox, Chrome, Edge and Safari) could not have been attacked. Clients that do not enforce it could have been targeted, and the site says it does not know whether attackers used the flawed keys against them.

What to do now

1. Update your OS and browsers. This covers most people.
2. Update the CA bundle on servers and in images. The patched ca-certificates version depends on your distribution: Ubuntu ships 20260816ubuntu0.*, Debian 12 ships 20250419~deb12u2, Alpine ships 20261020-r0, Fedora ships 2026.2.92_v9.0.319. A single version cutoff will misclassify some of these, so check the incident site's table for your distribution and runtime. Regenerate the active trust store where your distribution requires it.
3. Rebuild images and restart services. Pull a fresh base image (docker build --pull --no-cache) so the updated bundle is baked in. Note that not all images are updated yet. A running container keeps the old one.
4. Test it. Run the two commands below. An SSL failure with HTTP 000 is the result you want.
5. Handle the stragglers. For built-in macOS tools, which Apple has not updated yet, the incident site publishes workaround commands. Bundled runtimes such as Node.js, Go, Java and certifi each need their own patched release.

curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-emudhra.we-have-a-problem.com/
curl -sS -o /dev/null -w "HTTP %{http_code}\n" https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

A client that no longer trusts the compromised intermediates fails both requests with an SSL error and prints HTTP 000:

curl: (60) SSL certificate problem: unable to get local issuer certificate
HTTP 000

A 200 means that client still trusts them.

To see which ca-certificates version you have:

dpkg -s ca-certificates | grep Version   # Debian, Ubuntu
apk info ca-certificates                 # Alpine
rpm -q ca-certificates                   # Fedora, RHEL

How Aikido helps

If you are an Aikido customer, container images are checked automatically. The check covers packages that ship their own certificate bundles as well as the system-provided trust store, and it raises a separate issue for each.

For packages with their own bundle, such as Python's certifi before version 2026.10.18, an image gets a Critical issue. For the system trust store, which still accepts chains through the compromised intermediates, it gets a High issue. Each issue comes with a fix that matches the steps above, and applications that embed their own roots need separate updates.

We also released Device Protection v1.10.20 as a hotfix for this issue. If you use Device Protection, we advise updating to it.

What happened: eight keys, and one of them is 4

eMudhra is an India-based certificate authority: it checks who runs a website and issues the certificate behind the browser padlock, and the root programs behind Firefox, Chrome, Apple and Microsoft trust it. An intermediate CA is a signing certificate that chains up to one of those trusted roots, and whoever holds its private key can sign a valid certificate for any domain.

On October 17, a researcher known as Wayne told the browser and operating system root program teams that the private keys of eight eMudhra intermediate CA certificates were compromised. To prove it, Wayne signed the message "We have a problem here" with each of the eight keys. The certificates date from April 2025. eMudhra generated the keys incorrectly, which means anyone can recover them from the public certificates.

A private key is a secret number that has to be impossible to guess. A properly generated key of this type is picked from a range of about 10^115 values, a 1 followed by 115 zeros. According to our team's analysis, every one of these eight keys is below 256, and one of them is 4.

One potential explanation for the small keys would be a classic type casting bug, where the large random number was accidentally casted to a byte. Another theory was old Go behavior where a decimal conversion would truncate the number to a single byte.

Four is also the number from xkcd 221, where a random number function returns 4 and a comment swears it was chosen by a fair dice roll. An attacker needed at most 256 guesses to find any of the eight keys, against the roughly 10^115 it should have taken, and a laptop can try all 256 before you finish this sentence. A three-digit bike lock has 1,000 combinations, so the lock on your bike gives a thief more work than these keys gave an attacker.

‍

Why browsers are fixed and curl may not be

Mozilla, Google, Apple and Microsoft distribute revocation information to their browsers through mechanisms such as OneCRL, CRLite and CRLSets, so a bad intermediate can be blocked without waiting for a software update. eMudhra also revoked the certificates, but only a client that checks revocation ever sees that.

Most command-line tools and runtimes do not check. They hold a list of trusted root certificates and accept anything that chains to one, so the only way to stop them trusting a compromised intermediate is to ship a new list. According to the incident site, many clients outside the browser ecosystem ignore revocation data entirely, so only a software update protects them.

macOS is the clearest example. Apple devices block the certificates at the OS level, yet the built-in curl reads /etc/ssl/cert.pem, which nothing has updated. A browser and a terminal on the same laptop can disagree about whether the same certificate is valid.

Containers add a delay of their own. A Docker image freezes its CA bundle at build time, so every image built before the fix, and every image built from an old base layer since, still trusts the compromised intermediates until someone rebuilds it. Some examples as of October 22nd include: grafana/grafana:latest, mysql:latest, jenkins/jenkins:latest & bitnami/postgresql:latest.

How certificate trust works, briefly

A certificate is a website's digital ID card. When you open an HTTPS site, the server sends its certificate and your client checks that the name matches the site, the dates are valid and the signature comes from someone it trusts.

The signer is a certificate authority (CA). Your operating system or browser ships with a built-in list of root CAs it trusts. Roots stay offline and delegate the daily work to intermediate CAs, which sign the certificates that websites actually use. A certificate that chains up through an intermediate to a trusted root is accepted.

An intermediate's private key can sign a valid certificate for any domain, so a leaked key hands out the root's authority until clients are told to stop trusting it.

Timeline

Updates and sources

Oct 22, 2026: First published. Patch status changes daily, so check the incident site's table for your distribution and runtime.

Sources:

• eMudhra Intermediate CA Compromise, incident site maintained by Dennis Jackson and contributors
• Mozilla incident report, as linked from the incident site

‍