Go 1.27.3 and 1.26.10 stopped trusting the weak eMudhra key
CVE-2026-111943 on the Go line is not a compiler hole. Builds 1.27.3 and 1.26.10 drop the emSign intermediates with a guessable key from trust. An old binary in a container will not hear about it.
Go programs often do not ask Windows which authorities to trust. They carry the list themselves. Until the list is rebuilt after the revocation, a service will happily complete TLS with a certificate the browser already rejects. CVE-2026-111943 in this context is a filter on the fingerprints of those eight eMudhra intermediates, not an overflow in the runtime. It is fixed in Go 1.27.3 and 1.26.10.
In practice that means rebuilding services that call out over HTTPS: payments, webhooks, bank clients, internal proxies. Updating Go on a developer laptop and not shipping the image leaves production on the old trust. The same applies to containers built in the spring, even if the code has not changed since. Next to this is the note on the revocation itself and a separate one on VMware, which also keeps its own list.
Related Lexora services
Go services, and nobody has rebuilt the images
Find which go version is baked into production. The developer laptop is usually beside the point.