By ByteBot
Go shipped an emergency security update today. Go 1.27.3 and Go 1.26.10 hardcode a block against eight eMudhra intermediate CA certificates whose private keys were confirmed compromised over the weekend. The fix is live — but it only activates when you rebuild your binary. Upgrading Go on your build server without rebuilding your services accomplishes nothing.
What Happened to eMudhra
On Saturday evening, October 17, a security researcher reported to the Chrome Root Program that the private keys of eight eMudhra subordinate CA certificates had been compromised. Mozilla received the same report two hours later. Chrome and Firefox blocked all eight certificates the same day. Apple followed on the 19th. Microsoft on the 20th.
The certificates — eight DV, EV, OV TLS, and OV code-signing intermediates issued under the emSign Root TLS CA – G3 and emSign Root CS CA – G3 — were revoked in the CCADB for ‘cACompromise’. That designation means the private key itself is in hostile hands. An attacker holding a compromised intermediate CA key can issue fraudulent certificates for any domain and run man-in-the-middle attacks on HTTPS traffic.
Browsers handle this with real-time revocation checks and auto-updates. Compiled Go binaries do not. A Go service running today on last week’s build has no idea those intermediates are compromised.
What Go Did About It (CVE-2026-111943)
The Go team’s response is blunt and deliberate. Go 1.27.3 and 1.26.10 add a hardcoded list of eight SHA-256 SPKI hashes to crypto/x509. The Verify function now rejects any certificate chain that passes through these intermediates. There is no way to disable this. No GODEBUG flag. No environment variable override. The Go team decided that no production system should trust keys known to be compromised — and they are not offering an escape hatch.
The fix is tracked as CVE-2026-111943 and was backported to both the Go 1.26 and 1.27 branches. Details on the SPKI filtering implementation are in Go issue #82345.
The Mechanic You Cannot Miss
This is the part that trips teams up. Unlike a patch to a web server config or a package update, Go security fixes are compiled into the binary. A running Go service on Go 1.27.2 is not protected by today’s release. The binary has to be rebuilt against Go 1.27.3 and redeployed.
Upgrading Go on your build server is step one. It is not the only step. Every Go service that handles TLS connections needs a full rebuild cycle — including services in containers. Each container image must be rebuilt from scratch, not patched on top of an existing layer.
What You Need to Do Now
- Run
go versionon your build servers and confirm you are on 1.27.3 or 1.26.10 - Download the updated toolchain from go.dev/dl if needed
- Rebuild all affected services:
go build ./... - Rebuild container images from scratch — do not layer the fix on top of an existing image
- Redeploy
If your services connect to external sites or APIs that still use eMudhra-issued certificates, those connections will fail after rebuilding. That is the correct behavior. Those sites need to reissue their certificates from a non-compromised intermediate. There is no workaround on your end.
If You Are on Go 1.25 or Older
There is no patch for Go 1.25 or earlier. Those versions are out of support, and the fix was not backported beyond the 1.26 branch. If your codebase is still on Go 1.25, this incident is a hard stop: you need a Go version upgrade, not a patch. The Go team has been signaling this for months. This is the moment it becomes urgent.
Python and Other Ecosystems
The same eMudhra compromise affects Python users through the certifi CA bundle. The fix is simpler: pip install --upgrade certifi gets you to certifi 2026.10.19, which removes the emSign roots. Also update pip to 26.2.2 and uv to 0.13.4 if you use those tools. No rebuild required — one of the advantages of shipping trust as a data package rather than compiled code. The Python community thread has the full package list.
CA Compromise Is Now a DevOps Event
CA compromise used to be an ops problem: swap the certificate, move on. This one hits your build pipeline directly. Compiled Go binaries embed trust logic, which means CA revocation is now a trigger for a full rebuild-and-redeploy cycle across your services. If your team does not have a documented emergency rebuild runbook, today is a good moment to write one.
The golang-announce mailing list is where these incidents land first — subscribe if you haven’t. The Mozilla security post has the full timeline if you need to brief stakeholders on the incident scope.
