Executive Summary
eMudhra revoked eight intermediate certificate authorities in October after concluding their private keys could be recovered, and about 30,800 certificates hung off the affected hierarchies. Most major Go projects, Kubernetes vendors and container base images have since shipped a denylist. The cryptography work is finished. The distribution work is not.
The finding is about where the fix lands. A node image is rebuilt by its vendor and changed underneath you. Your own containers are not, because each image carries a root store baked in at build time and never inherits the host store. Google states this outright in its own bulletin. A cluster that is fully patched at the node can still run workloads that trust a revoked authority, and nothing will say so until a handshake fails. Treat it as an inventory problem and start by listing every image you own that opens outbound TLS.
The eMudhra CA compromise put a certificate authority most engineers had never heard of into the base layer of production images, and the browsers have named a date. On 16 November, certificates newly issued under the emSign G1 hierarchy stop being trusted by Chrome and Firefox.
TLS clients pick who to trust by reading a list of root certificates. On Linux that list is a file, usually under /etc/ssl/certs. Change the file and the client stops trusting the authority. That is the whole mechanism, which is why “distrust this authority” sounds like a one-line change.
The list exists in more than one place. The node image carries one, and every container image carries its own, copied at build time from whatever base it started from. Go programs read the system store on most platforms, which is why Go needed a code change rather than a certificate update.
Three of the four places the root lives are yours to fix
The node image is the layer you get for free. Google’s bulletin lists the GKE patch versions for Container-Optimized OS and Ubuntu node pools and recommends a manual upgrade even where auto-upgrade is enabled. cert-manager moved its base images to Debian 13 in v1.20.5, which no longer carries the emSign root and blocks AAA Certificate Services as a precaution. Istio dropped trust for the same intermediates in 1.31.3.
Go’s own advisory explains the design. The fix is CVE-2026-111943, tracked as GO-2026-6809, and it covers crypto/x509 before 1.26.10 and 1.27.0-0 through 1.27.2. The advisory notes that Go uses the system root certificates on most platforms, and that in some narrower cases those stores are not updated without further action. So the runtime keeps its own denylist and returns an error on Verify. Red Hat rates the issue Important at CVSS 6.8.
The layers that stay broken are the ones you built. Google’s wording is worth reading twice. Customer application containers do not inherit the host node’s root CA store and must be updated independently. Veeam says the same about Kasten and adds that older versions have no workaround, because the trust store is part of each container image. You cannot patch a baked-in file from outside. You rebuild, or you run the vulnerable thing.
The upgrade will break connections, and that is correct behaviour
Both cert-manager and Veeam warn that after the upgrade, connections to endpoints whose certificates chain to the emSign root or to AAA Certificate Services may fail with TLS errors. They describe that as expected. An endpoint still presenting a certificate from a revoked authority needs a new certificate, and until it gets one the client is doing exactly what you asked.
So the failure is not a clean cutover. It is a handshake error in a service nobody connected to the change, at a time nobody wrote down.
eMudhra moved the affected client base onto a separate G1 RSA root, and that root now has its own end date. Certificates already issued keep working in Chrome and Firefox, but nothing new will. Apple removes the hierarchy on 30 November, including certificates issued before that date.
So the place you migrate to has eight days on it from the day this publishes. eMudhra says the United States region is still mid-transition. Anyone who treated the move from G3 to G1 as the fix has a second migration they have not started, and 30,800 certificates is not a number you absorb twice in six weeks.
What to ask before 16 November
The cryptography was never the hard part. Eight revoked intermediates, one CVE, a denylist in a standard library. The hard part is that trust stores are distributed across thousands of images with no registry that lists them, and no vendor can patch on your behalf.
Three questions worth answering this week. Which of your images open outbound TLS, and do you know what base each was built from? Can you rebuild and redeploy every one of them inside eight days? And when a handshake starts failing, will the alert name the image that caused it?
Related reading. We covered the same boundary from the other side in The gVisor Speedup Was Never in the Code, where the isolation a runtime promises depends on host kernel work nobody shipped.
Get the next one before it is old news
Independent analysis of cloud-native infrastructure, Kubernetes and data center economics. No vendor spin.