Go Urgent Releases Reject Compromised eMudhra Intermediate Certificates

Key facts from the Go Blog post:

• Mozilla added eight eMudhra intermediate certificates to OneCRL on October 17.
• The affected keys were weak enough that private keys could be recovered in microseconds.
• The patched releases are Go 1.27.3 and 1.26.10, shipped as the first URGENT track release.
• Go reports that patched releases were live worldwide in under seven and a half hours from notification.
• Binaries must be rebuilt with the patched releases to reject the certificates automatically.

Go 1.27.3 and 1.26.10 Reject eMudhra Intermediate Certificates #

The incident began when Mozilla blocked eight eMudhra intermediates in Firefox, and researchers then found the keys were weak. The post says the root was present in most trusted root programs. That meant anyone holding the recovered private keys could sign TLS certificates for any domain, without proving control of that domain, and then impersonate a TLS server to a client that trusted the root.

For Go users, the exposure is man-in-the-middle attacks on TLS connections. The fix is therefore not a configuration change but a change in how Go's runtime verifies certificate chains. Any service that depends on Go's TLS verification, including code using net/http or crypto/tls, is in scope.

How Go's TLS Verifier Removes Trust on Each Platform #

Go calls its TLS verifier whenever net/http or crypto/tls connects to a TLS service. On Windows and macOS, the verifier delegates these checks to platform APIs. On Linux, which has no platform API for this, Go uses its own verifier implementation. The post explains that Linux lacks a uniform built-in revocation mechanism.

The team chose an URGENT track release because it wanted to protect users on every platform quickly, including users who might not receive platform updates in time. This means the trust removal is delivered through a Go release, so teams that ship their own binaries need to rebuild them rather than wait for an operating system update.

Timeline: Go Patched the eMudhra Issue in Under Eight Hours #

The post lists these steps, all in PDT:

• 11:45: an independent external researcher alerted the Security team to removals of trust in the eight intermediates.
• 12:30: Mozilla independently reported the issue and asked Go not to disclose it immediately.
• 14:00: a patch blocking chains through the compromised intermediates was finalized and tested against certificates signed with the recovered keys.
• 15:00: work began on releasing Go 1.27.3 and 1.26.10.
• 19:13: the releases were finalized and announced publicly.

The public announcement was deliberately vague. The post quotes it as

"blocking trust in a small set of intermediate certificates due to specific security concerns around their operation"

, with users urged to upgrade immediately. The team says this was meant to let other defenders protect users without showing attackers how the issue could be exploited. By the morning of October 20, numerous independent researchers had publicly disclosed the weak keys.

Rebuilding Go Binaries That Make TLS Connections #

Any Go binary that talks to network services over TLS needs a rebuild with the patched toolchain, including binaries that reach TLS through a dependency such as gRPC. The post states that binaries rebuilt with Go 1.27.3 and 1.26.10 automatically reject certificates issued by the compromised eMudhra intermediates. This suggests that a binary built with an older toolchain does not gain this protection just because the host runs a newer Go installation.

To check a toolchain, run go version. To check which Go version built a binary, run go version -m followed by the binary path. The post also describes govulncheck, which can determine whether a binary is affected when run with -mode=binary, and gives an install command that sets GOTOOLCHAIN to go1.27.3+auto. The post does not state which earlier Go releases were affected.

Release Process Took Just Under Four and a Quarter Hours #

The team says the release process took longer than expected because of issues that had not been problematic in multi-day releases. PRIVATE track fixes are pre-announced three to seven days before release. The post says an URGENT release could also have been pre-announced when the process began, which would have given users at least a few hours to prepare. The team says it has since made changes to improve release efficiency.

Linux Revocation Support Is Planned After This Incident #

Windows and macOS rely on platform revocation mechanisms, but Linux does not have a similar mechanism in Go, and the post names this as a major reason for the expedited release. The team plans to prioritize revocation support on Linux to mitigate this class of issues. Part of that work may involve adding support for the upki project, which the post links to issue #82402. For Linux deployments, this means revocation of certificates like these still depends on Go releases until that work lands.