Go corrige crypto/x509 con las versiones 1.27.3 y 1.26.10
Las versiones publicadas el 19 de octubre filtran rutas de certificados con determinados intermedios en crypto/x509, como corrección de seguridad CVE-2026-111943.
Go publicó el 19 de octubre las versiones 1.27.3 y 1.26.10 con una corrección de seguridad para crypto/x509, la biblioteca estándar que analiza y valida certificados. El cambio forma parte de CVE-2026-111943 y afecta al resultado de la verificación de ciertas cadenas; no es una actualización genérica de los almacenes de certificados de Linux, Windows o macOS.
El commit describe la decisión como dejar de confiar en un conjunto reducido de certificados intermedios. Go los identifica por el hash SHA-256 de la información de clave pública (SPKI) y filtra las cadenas que los contienen antes de devolverlas desde la función Verify. Esa comparación por huella delimita la mitigación a certificados concretos: el cambio no equivale a retirar una raíz completa del almacén del sistema.
-InfraCrew dice: a veces el cambio de política cabe en una lista de hashes; el trabajo de encontrar qué binarios los usan, no tanto.-
Qué cambia cuando una conexión valida TLS
Una cadena de certificados enlaza el certificado del servicio con una autoridad raíz de confianza, normalmente mediante uno o varios certificados intermedios. Si la única ruta válida de un servidor pasa por uno de los intermedios filtrados, Go deja de devolverla como confiable; la aplicación puede fallar al validar el par TLS. Si hay otra cadena válida que no contiene esos certificados, la verificación puede encontrarla y continuar.
La implementación cubre la verificación de Go y también filtra las cadenas que devuelven los validadores nativos de macOS y Windows. El punto de aplicación sigue siendo el código Go que usa crypto/x509, de modo que el síntoma visible aparecerá en servicios, agentes o herramientas construidos con una versión anterior cuando contacten con un endpoint cuya cadena coincida. No hay indicios en las notas de que todos los certificados emitidos por una entidad concreta hayan dejado de ser aceptados.
El proyecto vincula el cambio a CVE-2026-111943, pero sus notas públicas no aportan una puntuación CVSS ni describen un método de explotación. Conviene separar la mitigación confirmada de la explicación causal: el commit documenta qué cadenas filtra; la información pública consultada no permite afirmar que se haya comprometido una autoridad certificadora en general ni que exista explotación activa.
-InfraCrew dice: una alarma de TLS merece seguimiento; convertir cada fallo de certificado en “brecha global” no ayuda a nadie.-
La versión del compilador importa en el despliegue
Para incorporar la corrección, los equipos deben actualizar la toolchain a 1.27.3 o 1.26.10 en las ramas correspondientes, recompilar los componentes Go afectados y desplegarlos. Cambiar el compilador instalado no modifica por sí solo los ejecutables que ya están corriendo. En clústeres, plataformas de observabilidad, agentes de backup y controladores de red, conviene localizar primero qué imágenes y servicios se construyen con Go y qué versión usó cada pipeline.
La prueba más útil es verificar en preproducción las conexiones TLS que esos componentes mantienen con servicios externos y endpoints internos, incluidos los que usan certificados renovados recientemente. Hay que observar los fallos de validación y confirmar la cadena que presenta el servidor, sin relajar la verificación ni introducir excepciones permanentes para recuperar conectividad. Si un servicio falla después de actualizar, la cadena observada ayuda a distinguir una dependencia del intermedio filtrado de un problema de nombre, caducidad o raíz privada.
Las notas oficiales confirman las dos versiones corregidas, pero no asignan un comportamiento universal a todas las aplicaciones hechas en Go. El alcance práctico depende de que el proceso use crypto/x509 y de la cadena presentada por el servidor. Bibliotecas de terceros, verificadores personalizados y certificados privados pueden alterar el recorrido; por eso el inventario del pipeline y una prueba por servicio aportan más que actualizar nodos sin identificar los binarios.
-InfraCrew dice: el rollout correcto empieza en el pipeline que crea el binario, no en una terminal cualquiera del clúster.-
Qué revisar hoy
Los responsables de plataforma pueden comprobar la versión de Go declarada en los pipelines, actualizar las ramas que construyen software propio y priorizar componentes que establecen conexiones TLS salientes. Después del despliegue, conviene vigilar los errores de verificación en métricas y logs y validar cualquier incidente con la cadena real del endpoint. La corrección está publicada en las dos ramas actuales indicadas por Go; no hace falta esperar a una versión futura para empezar la prueba.
La limitación del aviso también es relevante: la documentación pública no explica la causa operativa que llevó a bloquear esos intermedios. La medida verificable es el filtrado de cadenas por huella, con una consecuencia posible de disponibilidad si una dependencia solo presenta una ruta afectada. Hasta que Go publique más contexto, las respuestas deben basarse en versiones, huellas y pruebas observadas, no en atribuciones más amplias que el cambio no demuestra.
Diccionario de la Crew
crypto/x509 — Paquete de la biblioteca estándar de Go para analizar y verificar certificados X.509.
Certificados intermedios — Certificados subordinados que enlaza un certificado de servicio con una autoridad raíz.
SPKI — Estructura que contiene la clave pública y su algoritmo dentro de un certificado.
Cadena de certificados — Secuencia de certificados que permite validar la identidad presentada hasta una raíz de confianza.
Verify — Función de crypto/x509 que devuelve las cadenas que superan la verificación solicitada.
