Cilium actualiza tres ramas para bloquear certificados eMudhra comprometidos
Cilium publicó parches para 1.18, 1.19 y 1.20 que actualizan Go y rechazan certificados intermedios eMudhra comprometidos, el origen de CVE-2026-111943.
Cilium publicó el 23 de octubre tres parches fuera de calendario para bloquear CVE-2026-111943: las versiones 1.18.16, 1.19.10 y 1.20.4. Las tres corresponden a las ramas estables que el proyecto mantiene. El cambio visible es una actualización del runtime de Go a 1.26.10, que deja de confiar en una serie de certificados intermedios de eMudhra cuyas claves privadas fueron comprometidas.
El fallo está en crypto/x509, la biblioteca de Go que valida certificados X.509. Una CA intermedia comprometida puede firmar certificados para dominios que encadenen con una raíz confiable; un intermediario en posición de red podría intentar suplantar un servicio TLS sin que el nombre del dominio por sí solo revele el problema. El issue del proyecto Go describe la mitigación: una lista explícita de intermediarios que la validación debe rechazar, incluso en ciertos casos estrechos donde actualizar el almacén de raíces del sistema no basta.
-InfraCrew dice: revocar la confianza a tiempo es menos vistoso que rotar una contraseña, pero aquí la contraseña no era el control que fallaba.-
Para Cilium, la noticia importa porque el producto incluye componentes escritos en Go y empaquetados en sus imágenes. El parche actualiza ese runtime dentro de las versiones de Cilium indicadas; no describe un error en las políticas de red de Cilium ni demuestra que una instalación haya sufrido una interceptación. El riesgo depende de la cadena concreta que una conexión presente, del almacén de confianza utilizado y de si el componente llega a validar una conexión TLS con esos certificados.
La distinción evita dos errores comunes: un runtime compartido amplía el alcance, pero no convierte todos los componentes en vulnerables. Un fallo de una biblioteca estándar puede alcanzar a muchos productos que la integran, pero eso no significa que cada función del producto quede expuesta del mismo modo. Tampoco equivale a una intrusión confirmada en los clusters que ejecutan Cilium. Lo que sí confirma el aviso es que el proyecto consideró necesario publicar parches de seguridad fuera del ritmo normal y actualizar el Go embebido en sus builds.
Las versiones anunciadas permiten actuar sin saltar de rama: 1.18.16 para la línea 1.18, 1.19.10 para 1.19 y 1.20.4 para 1.20. El operador debería identificar primero qué imagen y versión ejecuta en cada cluster y elegir la actualización correspondiente a su línea mantenida. En entornos con ventanas de cambio estrictas, el trabajo de validación debe incluir el estado de los agentes y operadores después del rollout, además de las conexiones TLS salientes que esos componentes necesiten realizar.
-InfraCrew dice: cuando el fix viaja dentro de la imagen, cambiar solo el paquete Go del nodo puede dejar intacto justo el binario que necesitabas corregir.-
CVE-2026-111943 no implica por sí sola que haya tráfico interceptado. El problema es la capacidad de aceptar una cadena que use intermediarios afectados; la evidencia pública citada en el issue de Go describe la mitigación de confianza, no víctimas de Cilium ni explotación dirigida contra clusters. Para equipos con almacenes personalizados, sidecars propios o certificados fijados de forma independiente, conviene revisar qué parte del stack realiza la validación: actualizar Cilium no modifica automáticamente todos los runtimes y almacenes que conviven en los nodos.
La publicación también recuerda que la seguridad de TLS no termina en el ingress. Un controlador, agente o proceso auxiliar que sale a consultar una API depende de la cadena de certificados que su runtime acepta. El parche de Cilium corrige su componente empaquetado, mientras que imágenes derivadas y herramientas externas necesitan su propia verificación de versiones; el nombre del cluster no basta para saber qué biblioteca está ejecutando cada contenedor.
Diccionario de la Crew
CVE — Identificador público asignado a una vulnerabilidad concreta.
CA intermedia — Autoridad certificadora que puede firmar certificados y que, a su vez, encadena con una raíz confiable.
crypto/x509 — Paquete de Go que procesa y valida certificados X.509.
TLS — Protocolo que cifra y autentica conexiones entre aplicaciones.
MITM — Intermediario que intenta observar o alterar una comunicación entre dos extremos.
