The eMudhra CA Compromise: Why Patching Kubernetes Nodes Isn't Enough

In October 2026, a researcher discovered that eMudhra, a certificate authority, had generated eight certificate-signing private keys that were single-byte numbers (4, 56, 66, 115, 155, 156, 230, and 237) instead of random 384-bit values, so anyone could recover them from the public CA certificates in under a second. Anyone who recovered an affected TLS signing key could issue certificates for domains they did not control. An attacker who also intercepted or redirected traffic could then impersonate legitimate services to clients that still trusted the compromised issuers. Your own certificates do not have to come from eMudhra for your connections to be at risk. If a client accepts the forged certificate, the attacker can receive the credentials and request data sent over that connection and return altered responses.

Major browsers received updates to block the affected certificates, but those protections do not automatically extend to Kubernetes. Nodes, container images, application runtimes, and cluster configuration can each supply trusted certificates or apply their own verification rules. Remediation depends on which ones a running component actually uses.

Where Kubernetes keeps its trust

A Kubernetes cluster does not use a single shared trust store. A container runtime normally relies on certificates from the node, applications may include their own bundles inside images, and language runtimes can provide another set. Additional CA bundles can also be stored in Kubernetes configuration and mounted into workloads.

These copies are updated separately. A running process may also retain certificates loaded before an update, so correcting a file does not necessarily correct the application's trust decisions. The following sections explain what to update at each layer and when a restart or reload is required.

The exposure concerns connections that trust the affected public issuers. A connection restricted to a private cluster or mesh CA is not automatically exposed by this incident.

The diagram compares a typical image pull with an application connection. The application may use one or more of the sources shown, depending on its TLS configuration.

Node and workload trust follow separate update paths. Each running client must load any changed certificates.

1. The node: container runtime and control plane

When Kubernetes downloads an image, the kubelet asks the container runtime, such as containerd or CRI-O, to retrieve it. The runtime connects to the registry and verifies its HTTPS certificate using the node's trusted CAs. A registry-specific CA configured for containerd or CRI-O is added to that pool rather than replacing it, so the node bundle still applies to those registries.

If that trust configuration still accepts the compromised issuers, an attacker on the network path could impersonate the registry. This happens before the workload starts, so updating certificates inside the workload's image does not protect the download.

Install the distribution's CA update or replace the node with a fixed node image. Then restart affected processes that cached the old certificates. This includes the container runtime and any relevant node or control-plane components. A newly started diagnostic tool can use the updated bundle while a long-running service still uses the old one.

The control plane also needs attention. In kubeadm clusters, the API server and controller manager mount certificate directories from the node. These stores can be used for external HTTPS connections. For example, the API server uses system roots for an admission webhook when its configuration omits an explicit caBundle; a supplied bundle must be reviewed separately.

Use the supported static-Pod restart procedure for kubeadm control-plane components. Deleting their mirror Pod objects through the API does not restart the underlying containers. Roll through a replicated control plane one node at a time and verify readiness before continuing.

Also deploy applicable Kubernetes and runtime releases containing the certificate-verification fix. For managed Kubernetes, follow the provider's control-plane and node-image rollout guidance. Provider updates do not automatically replace your application images or custom CA bundles.

2. The image: the container's own trust store

Updating a node's CA bundle does not update the certificates inside its container images. Many images include their own /etc/ssl/certs, containing certificates installed when the image was built.

The disclosure site provides test endpoints that present certificates from affected issuers. The following command checks the emSign endpoint using a particular curl image:

kubectl run curl --image=curlimages/curl:8.22.0 --restart=Never --rm -i -- \
  -sS -o /dev/null -w '%{http_code}\n' https://dv-g3b-emudhra.we-have-a-problem.com/

The comparison below uses two images on the same node with an updated CA package:

The older image still accepts the affected certificate because its own bundle predates the fix. For images you maintain, update the CA package, rebuild, and redeploy. For vendor images, use a release containing the correction and confirm the running Pods have adopted it.

This checks curl's trust configuration. An application in the same container may use a different bundle or runtime, and rejecting this endpoint does not prove that every alternative certificate chain is blocked.

3. The runtime: the application's certificate checks

Applications do not always use the image's /etc/ssl/certs. Some runtimes include their own trusted certificates. Others also contain code that rejects the compromised signing keys, even if the trust store still contains the affected roots.

Go is particularly relevant to Kubernetes because its control-plane components and many controllers are written in Go. Go 1.27.3 and 1.26.10 added a blocklist to crypto/x509 that rejects certificate chains containing the compromised keys.

A test client built with three Go versions illustrates the difference. With the same outdated CA bundle, the results were:

The updated clients reject the affected certificate while still accepting the control connection. This protection is compiled into the application: deploy a release built with a patched toolchain, or rebuild and redeploy it yourself. A version declared in go.mod does not establish which toolchain built the deployed binary. Check the binary's build metadata as well as its behavior.

Java, Node.js, Python, and Rust applications also need runtime-specific checks. Review the runtime's security guidance and any separately bundled CA packages, such as Python's certifi. Updating the operating system's certificates does not necessarily update those copies.

4. The cluster configuration: CA bundles in Kubernetes objects

Kubernetes objects can hold CA bundles that workloads and controllers use to verify connections. Updating a node or container image does not replace these stored copies.

Review the places where your applications receive trusted certificates:

• ConfigMaps and Secrets, including Argo CD's argocd-tls-certs-cm, Secrets containing ca.crt, and bundles referenced by Istio or Kasten.
• Kubernetes API configuration, including CA bundles in admission webhooks, APIServices, and CRD conversion webhooks.
• Application configuration, including CA settings in custom resources, Helm values, and bundles distributed by trust-manager.

Use the SHA-256 certificate fingerprints in the disclosure site's affected root list to identify those roots. Review explicitly trusted affected intermediates too. Do not remove unrelated private cluster or mesh trust anchors merely because they are stored in the same type of Kubernetes object.

If you use trust-manager, check its default CA package and any repository or tag overrides. Charts through v0.25.0 install an affected package by default; v0.26.0 installs a corrected package. Updating the default package does not remove affected certificates supplied through additional Bundle sources.

Available fixes and upgrade guidance

The tables below list the required action for Kubernetes components, managed clusters, and cloud-native tools as of the November 9, 2026 snapshot. Consult the linked project guidance for newer versions before planning a rollout. Custom bundles, helper programs, and other image variants still require separate checks.

Kubernetes and container runtimes

Managed Kubernetes

A provider update being available does not establish that it has reached your cluster. Check the control plane, node image, and rollout status, then address customer-managed workloads separately.

Service mesh, gateways, and networking

Certificates, identity, and policy

Delivery and supply chain

Container builds, registries, and scanning

Observability, data, and platform

Conclusion

The eMudhra compromise shows why a Kubernetes security update can remain incomplete after the nodes have been patched. Containers can retain older CA bundles, applications can use separate runtime stores, and cluster configuration can supply certificates that survive both updates. Running processes may also need a restart before any correction takes effect.

For each affected client, identify how it verifies certificates, apply the relevant update, and confirm that it rejects the compromised chains while legitimate connections still work. The outcome to verify is the behavior of the running platform, including the images, configuration, and helper programs it actually uses.