Go 1.27.3 and 1.26.10 Distrust eMudhra CAs: CVE‑2026‑111943

• What happened: on October 17, Mozilla added eight intermediates issued under an eMudhra root, six for TLS and two for code signing, to OneCRL. Researchers found the keys could be recovered in microseconds, which would let anyone sign TLS certificates for any domain.
• Why Go acted itself: on Windows and macOS, Go hands certificate checks to the platform, but on Linux it uses its own verifier, and Linux has no uniform revocation mechanism. The denylist covers Linux and platforms that might not receive trust store updates.
• Speed: Go shipped the fix about seven and a half hours after the first notification, in its first release on the URGENT security track. By the morning of October 20, researchers had published the weak keys.
• Rating: the CVE record carries a CVSS 3.1 score of 6.8, added by CISA-ADP, and CISA's SSVC assessment of October 30 rates exploitation as none.
• Who must act: anyone running Go programs that make TLS connections through net/http, crypto/tls or a dependency such as gRPC.

Go Binaries That Must Be Rebuilt, and How to Find Them #

The fix lives in the standard library compiled into each program, so upgrading the Go installation changes nothing for binaries already built. The Go Security team's post, by Roland Shoemaker, says binaries rebuilt with Go 1.27.3 or 1.26.10 reject the compromised intermediates automatically. Teams need to rebuild every service, CLI tool and container image that talks TLS, starting with those that run on Linux.

The post names three checks. go version shows the installed toolchain, go version -m followed by a binary path shows which Go built that binary, and govulncheck -mode=binary on a binary reports whether it is affected by this issue. A binary that reports a Go version before 1.26.10, or 1.27.0 to 1.27.2, needs a rebuild with 1.27.3, 1.26.10 or a later release on those lines.

Where the Denylist Matters: Linux and Unpatched Trust Stores #

The CVE record states that on most platforms Go uses the system root certificates, but in narrower cases system trust stores may not be updated without further action. The denylist makes Certificate.Verify in crypto/x509 return an error for any of the distrusted intermediates, so a Go program refuses them even where the operating system still trusts the chain. On Linux this is currently the only protection, which is why the Go team plans revocation support there, including an investigation of the upki project in issue #82402.

What the URGENT Track Changed in Go's Release Process #

A normal Go security release is pre-announced three to seven days ahead. This time the team was alerted at 11:45 PDT on October 19, finished the patch at 14:00, started the release at 15:00 and announced it at 19:13, with deliberately vague wording so attackers would not learn how to exploit the keys before defenders had patched. The post says the release process alone took just under four and a quarter hours and that the team has since changed it to be faster, and that a short pre-announcement when the release starts would have given users a few hours to prepare.