Go 1.27.3 and 1.26.10: CVE-2026-111943, eMudhra certificates and why you must rebuild
On 19 October 2026 Go released versions that stop accepting eMudhra's compromised intermediates. Because the protection lives inside each binary, updating the toolchain is not enough: rebuild and redeploy.

On 19 October 2026 the Go team released versions 1.27.3 and 1.26.10, whose only security fix is in the crypto/x509 package and is tracked as CVE-2026-111943. The change stops accepting certificate chains that pass through the eight compromised intermediates of the eMudhra certificate authority. Eleven days earlier, on 8 October, versions 1.27.2 and 1.26.9 had fixed security issues in other packages. This article explains what changes, why updating Go requires rebuilding, and how to confirm that each service is protected.
The Go team's announcement is explicit: "We highly recommend immediately upgrading to this release."
An explanation for readers who do not run servers
Go is a language used to build web services, infrastructure tools and command-line applications; Docker, Kubernetes and Terraform are written in Go. Unlike PHP or Node.js, a Go program ships as a single compiled file that carries everything it needs.
That property changes how a fix is applied. The protection against eMudhra's forged certificates is in Go's standard library, and that library is copied into every program when it is compiled. Installing a new Go on a server does not change the programs already running: each one must be rebuilt with the fixed version.
What CVE-2026-111943 fixes
According to the announcement and issue 82345, Go distrusts a small set of intermediate certificates. The Verify function discards any chain that contains one of them, so they are no longer returned to callers. In practice, a server presenting a certificate issued with those keys will be rejected, regardless of which roots the system trusts.
That detail matters on Linux. There, Go takes its roots from the operating system, so updating ca-certificates also helps; but the block in 1.27.3 works even if the system is out of date or the program uses its own root set. Red Hat rates the case as Important, 6.8 on CVSS 3.1, and covers it in bulletin RHSB-2026-012.

October 2026 releases
| Version | Date | Security fixes |
|---|---|---|
| 1.27.3 and 1.26.10 | 19 October | crypto/x509: CVE-2026-111943, eMudhra intermediates |
| 1.27.2 and 1.26.9 | 8 October | The go command and the crypto/tls, html/template, net/http, net/textproto and os packages |
The releases are cumulative: 1.27.3 and 1.26.10 include the 8 October fixes. Lines older than 1.26 no longer receive updates from the project.
What to rebuild
- Your own services: update the Go version in the build environment and the
Dockerfile(for examplegolang:1.27.3), and thetoolchaindirective ingo.modif used. Rebuild and redeploy. - Continuous integration: confirm that runners do not use a cached Go image.
- Third-party tools written in Go: these depend on the vendor shipping a rebuilt binary. Review the release notes of agents, CLIs and Kubernetes operators that run with network access.
- Programs that cannot be rebuilt yet: updating the system's
ca-certificatesreduces risk on Linux when the program uses system roots, but it does not replace rebuilding.
Verification procedure
- Identify which version built each binary:
go version ./my-serviceprints the Go version used to build it, even for third-party binaries. - Confirm the version is 1.27.3 or 1.26.10, or later.
- Check that the deployed image matches that build, for example by comparing the running image digest with the latest build.
- Test rejection against the incident's test servers (
emudhra.we-have-a-problem.com) from the service itself or a program built with the same version: the connection must fail on the certificate.
Frequently asked questions
Is updating Go on the server enough?
No. A Go binary does not use the Go installed on the server; it carries its own copy of the standard library. Only a rebuilt binary includes the block.
Does it affect programs that make no outbound HTTPS connections?
The block protects Go when it acts as a TLS client or verifies certificates. A service that only accepts connections with its own certificate does not change, although rebuilding it is still worthwhile for the 8 October fixes.
Sources
- Go, release history.
- oss-security, Go 1.27.3 and 1.26.10 announcement.
- GitHub, golang/go#82345.
- Red Hat, RHSB-2026-012.
- Incident background: eMudhra certificate compromise.
Support rebuilding and redeploying
Xterra Engine updates Go build pipelines, images and deployments, and verifies which version each production binary carries. To request support or a quote, write to info@xterraengine.com or use the contact form.