CVE-2026-111943: eMudhra CA Compromise Explained

CVE-2026-111943 tracks Go's response to the eMudhra certificate compromise. The underlying problem reaches beyond Go: private keys belonging to a certificate authority were recoverable, and some clients could still trust certificates signed with them.

The part that deserves attention is how unevenly the fix reaches different software. A browser can reject a certificate while an API client on the same machine still accepts it.

What actually broke

Eight intermediate CA certificates associated with eMudhra had compromised private keys. Google's security team says those keys were generated with insufficient randomness.

CERT-In's advisory gives a striking detail: the affected P-384 private keys had values smaller than 256. That means the numbers themselves were below 256, not that they were 256-bit keys. The keys could be recovered almost instantly from their public counterparts.

This is a key-generation failure. The mathematics behind a strong algorithm does not help if its private key comes from a tiny, predictable set of values.

In its incident statement, eMudhra says the affected intermediates came from an April 2025 key-generation ceremony. It says its root CA private keys and other intermediate CAs were unaffected. That limits the scope to particular authorities; it does not make accepting their signatures safe.

How a forged certificate gets accepted

When an HTTPS client connects to a server, it checks a certificate chain. A server certificate is signed by an intermediate CA, which in turn chains to a root the client trusts. The client also checks the hostname, dates, certificate constraints, and applicable trust policies.

An intermediate CA's private key carries the authority to sign other certificates. Recovering that key can let an attacker issue a certificate for a hostname they do not control. If a client still trusts the chain, the certificate's signatures can validate even though the server is an impostor.

The attacker also needs to intercept or redirect the connection. Having the signing key does not automatically provide access to traffic. Mozilla's disclosure describes the risk as website impersonation, with the possibility of reading or modifying intercepted traffic.

That could matter to a service sending an authorization token or a confidential request body. The connection may be encrypted, but the client has authenticated the wrong endpoint.

There is an important limit to the public findings. Google reports that no TLS certificates chaining to the six affected TLS-issuing intermediates appeared in Certificate Transparency logs before its block. That rules out their use against CT-enforcing clients during that period. It does not settle what happened to clients without CT enforcement.

Certificate verification

Where the connection gets rejected

Compare a client that still trusts the issuer with one that has received the update.

Root authorityTrusted rootA known starting point

Intermediate CACompromised CARecoverable signing key

Server certificateForged certificateClaims a real hostname

An unpatched client may accept the impostor

The signatures can check out while the server identity is false. Encryption alone cannot correct that decision.

Simplified scenario: the attacker can intercept the connection, the chain was previously trusted, and the client has no effective revocation or Certificate Transparency protection.

Why backend clients need their own updates

Firefox received a block through OneCRL on October 17, 2026. Mozilla says distribution to standard configurations finished within three hours of the report, without a browser update or restart.

Backend software does not necessarily receive that protection. An HTTP library might use the operating system's roots, a runtime's bundled roots, or an explicitly configured CA file. Cloudflare's write-up describes this split between verification paths.

Editorial illustration of separate browser, operating-system, and application environments, each with its own certificate store.

Browser, operating-system, and application trust stores can update independently.

Updating the host does not replace a CA bundle baked into a container image. Updating a build toolchain does not change a compiled executable that is already running. And revoking a certificate at the CA only helps clients that receive and enforce the relevant revocation information.

For Go, the additional protection is a denylist in crypto/x509. The Go advisory explains that it covers cases where system trust-store updates may not reach an application. The fixed releases filter out chains containing the distrusted intermediates.

What to patch and how to check it

These are reference fixes as of October 22, 2026. Use the current supported release or your distribution's documented backport.

Component	Reference fix	Follow-through
Go 1.26 applications	Go 1.26.10	Rebuild and redeploy the executable.
Go 1.27 applications	Go 1.27.3	Update build images as well as deployed artifacts.
Applications using Mozilla NSS	NSS 3.131.1	Confirm the application loads the updated trust data.
Python applications using certifi	certifi 2026.10.19	Check each environment and packaged bundle.
OS and container CA packages	Your distribution's incident update	Check deployed images separately from their hosts.

The incident coordination site maintains a longer list of affected software and patches.

For an actual deployment, we would start with the processes making outbound TLS connections: services, background workers, CI jobs, package managers, agents, and administrative tools. For each one, identify the verifier and trust source, apply the appropriate update, and confirm the replacement artifact is running.

Then check the behavior. The coordination site publishes diagnostic hosts with affected chains, including these curl examples:

curl --head --connect-timeout 10 --max-time 20 \
  https://dv-g3b-emudhra.we-have-a-problem.com/

curl --head --connect-timeout 10 --max-time 20 \
  https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

A certificate-validation error is the expected result. A timeout or DNS failure tells you nothing about certificate rejection. Do not add -k or --insecure.

This checks that curl installation, not every application on the host. Run equivalent checks through the deployed application's TLS stack. The two URLs are spot checks; the coordination site lists more affected chains, including cross-signs.

Also test the legitimate endpoints the application needs. Distrust can break a real service whose certificate chains through a removed authority. The answer is to follow the issuer's migration guidance, rather than switching off certificate verification.

A few practical questions

Q: Is CVE-2026-111943 only a Go issue?

The CVE tracks Go's defensive update. The compromised CA keys can affect other clients that still accept the affected certificate chains.

Q: Do I need to replace my own website certificate?

Check its actual chain and the issuer's guidance. A certificate under a distrusted hierarchy may need replacing. Replacing an unrelated server certificate does not update your outbound clients' trust stores.

Q: Does a working website mean the patch is complete?

No. Verify the certificate-validation behavior of the clients you run, including services and containers. A browser's result does not establish what those clients trust.

Release references checked October 22, 2026. The linked upstream advisories carry subsequent updates.

Adaptive's defensive patch

We patched Adaptive in under an hour in response to the eMudhra certificate compromise. There was no apparent issue in our environment. We used Codex and Claude Code with Astra and Fable to implement and validate the patch as a precaution.

The eMudhra certificate compromise, explained