Go blocks compromised eMudhra CAs: what to do for CVE-2026-111943

The issue: CA private keys recoverable without specialist tools

On 20 October 2026, the Go Project published CVE-2026-111943: the crypto/x509 package did not block certificates issued by eight eMudhra/emSign intermediate CAs whose private keys were, in effect, public. This is a key generation flaw affecting an external Certificate Authority (eMudhra/emSign), whose intermediate CA private keys were trivially recoverable due to catastrophic entropy failure during P-384 key generation: eight intermediate CA private keys (six for TLS, two for code signing) were generated with scalar values of small integers, rendering them mathematically recoverable without specialist tools.

The reference CWE identified by Red Hat is CWE-295 (Improper Certificate Validation): the certificate verification process failed to block trust in intermediate certificates associated with a compromised CA, and a remote attacker presenting a certificate signed by these intermediate authorities can impersonate legitimate servers during secure connections, conduct a man-in-the-middle attack, and intercept or alter confidential communications.

Patched versions and how to verify

Go branch	Vulnerable versions	Patched version	Release date
Go 1.26	before 1.26.10	1.26.10	19 October 2026
Go 1.27	1.27.0-0 to before 1.27.3	1.27.3	19 October 2026

CVE-2026-111943 affects Go crypto/x509 in versions prior to go1.26.10 and from go1.27.0-0 until before go1.27.3. The patched versions are go1.26.10 and go1.27.3. Go does not check certificate revocation by default, so on a statically compiled binary the fix arrives only by recompiling: Go 1.26.10 / 1.27.3 no longer trust the eight eMudhra intermediate CA keys in crypto/x509 (CVE-2026-111943, GO-2026-6809), and since Go does not perform revocation checking, a recompiled binary is the solution.

To determine if a server is exposed:

go version

If the installed version is earlier than the patched ones, download the updated tarball from go.dev/dl, replace the /usr/local/go directory, and recompile all binaries that use it: updating only the toolchain on the build machine is not sufficient, every static executable that embeds it needs to be regenerated.

After updating, it is normal for connections to endpoints with certificates in those chains to fail: after the update a Go client may return x509: certificate signed by unknown authority or a related NoValidChains error. This is not a client bug, it is expected behaviour.

The three root CAs involved and the impact on AWS

Amazon Linux: golang packages are recompiled with the crypto/x509 patched as described in CVE-2026-111943 as a defence-in-depth measure against eMudhra intermediate CA certificates with weak private keys. The root CAs from which the compromised intermediates descend, with the corresponding SPKI SHA-256 hash published by AWS, are:

Root CA	SPKI SHA-256 (start)
AAA Certificate Services	bd153ed7b0434f6886b17...
emSign Root TLS CA – G3	c619e4780ed8e0abeda24...
emSign ECC Root CA – G3	8d417db2dd8bf5e3084d1...

Those using CloudFront or Application Load Balancer with OIDC/JWT authentication should check whether their certificate chains to one of these roots. AWS has confirmed that Amazon CloudFront is removing the root from the edge CA bundle by the target date of 28 October 2026, and ALBs with OIDC or JWT are being updated between 29–31 October, with new instances protected from 2 November: if the identity provider endpoint presents a certificate from one of those roots, it must be replaced with one issued by a trusted CA by 28 October, as indicated in the official advisory.

Timeline: a patch in 7.5 hours

Third-party sources reconstructing the incident timeline report that Mozilla added the eight eMudhra intermediates to OneCRL on 17 October, the Go security team was alerted on 19 October, and Go 1.27.3 and 1.26.10 shipped seven and a half hours later with a patch that rejects any chain passing through those intermediates. This is the first Go release classified as URGENT-track, a procedure different from the normal several-day advance notice cycle.

USN-8875-1: the Ubuntu advisory you might struggle to find

For those searching without results in English: USN-8875-1, published on 6 October 2026, concerns the Linux kernel on Ubuntu 22.04 LTS and 20.04 LTS. Among the fixes, it was discovered that the i.MX clock driver in the Linux kernel did not correctly handle certain failure conditions in memory allocation, leading to a null pointer dereference vulnerability; a local attacker could exploit it to cause a denial of service (system crash) — CVE-2022-3114. After the standard update the system should be rebooted; since there was an ABI change, anyone with third-party kernel modules must recompile and reinstall them.

This week's roundup

In the coming days (2–8 November) check official sources: new Ubuntu Security Notices at ubuntu.com/security/notices, Wordfence Intelligence and Patchstack advisories for the most common WordPress plugins in shared hosting environments, and the CloudLinux changelog for OS and CageFS. Without firm figures at press time for that period, the usual rule applies: cite zero CVEs or versions from memory—only those you've read on the data owner's official page.