Go 1.27.3 y 1.26.10: CVE-2026-111943, certificados de eMudhra y por qué hay que recompilar
Go publicó el 19 de octubre de 2026 versiones que dejan de aceptar los intermedios comprometidos de eMudhra. Como la protección queda dentro de cada binario, actualizar el compilador no basta: hay que recompilar y redesplegar.
El 19 de octubre de 2026 el equipo de Go publicó las versiones 1.27.3 y 1.26.10, cuya única corrección de seguridad está en el paquete crypto/x509 y se registra como CVE-2026-111943. El cambio deja de aceptar las cadenas de certificados que pasan por los ocho intermediarios comprometidos de la autoridad eMudhra. Once días antes, el 8 de octubre, las versiones 1.27.2 y 1.26.9 habían corregido fallas de seguridad en otros paquetes. Este artículo explica qué cambia, por qué en Go la actualización exige recompilar y cómo comprobar que cada servicio quedó protegido.
El anuncio del equipo de Go es explícito: «recomendamos encarecidamente actualizar de inmediato».
Explicación para quien no administra servidores
Go es un lenguaje con el que se construyen servicios web, herramientas de infraestructura y aplicaciones de línea de comandos; Docker, Kubernetes y Terraform están escritos en Go. A diferencia de PHP o Node.js, un programa en Go se entrega como un único archivo ya compilado que lleva dentro todo lo que necesita.
Esa característica cambia la forma de corregir. La protección contra los certificados falsos de eMudhra está en la biblioteca estándar de Go, y esa biblioteca queda copiada dentro de cada programa al compilarlo. Instalar Go nuevo en un servidor no modifica los programas que ya están en marcha: cada uno debe volver a construirse con la versión corregida.
Qué corrige CVE-2026-111943
Según el anuncio y la incidencia 82345, Go bloquea un conjunto pequeño de certificados intermedios. La función Verify descarta cualquier cadena que contenga alguno de ellos, de modo que ya no se devuelven a quien llama. El efecto práctico es que un servidor que presente un certificado emitido con esas claves será rechazado, sin importar qué raíces de confianza use el sistema.
Ese detalle importa en Linux. Go toma ahí las raíces del sistema operativo, de modo que actualizar ca-certificates también ayuda; pero el bloqueo de la versión 1.27.3 funciona aunque el sistema siga desactualizado o aunque el programa use su propio conjunto de raíces. Red Hat califica el caso como importante, con 6.8 en CVSS 3.1, y lo trata en su boletín RHSB-2026-012.
Versiones de octubre de 2026
| Versión | Fecha | Correcciones de seguridad |
|---|---|---|
| 1.27.3 y 1.26.10 | 19 de octubre | crypto/x509: CVE-2026-111943, intermedios de eMudhra |
| 1.27.2 y 1.26.9 | 8 de octubre | Comando go y paquetes crypto/tls, html/template, net/http, net/textproto y os |
Las versiones son acumulativas: 1.27.3 y 1.26.10 incluyen las correcciones del 8 de octubre. Las ramas anteriores a 1.26 ya no reciben actualizaciones del proyecto.
Qué recompilar
- Servicios propios: actualizar la versión de Go en el entorno de compilación y en el
Dockerfile(por ejemplogolang:1.27.3), y la directivatoolchaindelgo.modsi se usa. Recompilar y redesplegar. - Integración continua: confirmar que los ejecutores no usan una imagen de Go en caché.
- Herramientas de terceros escritas en Go: dependen de que su fabricante publique un binario recompilado. Conviene revisar las notas de versión de agentes, CLIs y operadores de Kubernetes que se ejecuten con acceso a la red.
- Programas que no se pueden recompilar todavía: actualizar
ca-certificatesdel sistema reduce el riesgo en Linux cuando el programa usa las raíces del sistema, pero no sustituye la recompilación.
Procedimiento de verificación
- Identificar con qué versión se compiló cada binario:
go version ./mi-serviciomuestra la versión de Go con que se construyó, incluso en binarios ajenos. - Confirmar que la versión es 1.27.3 o 1.26.10, o posterior.
- Comprobar que la imagen desplegada corresponde a esa compilación, por ejemplo comparando el digest de la imagen en ejecución con el del último build.
- Probar el rechazo contra los servidores de prueba del incidente (
emudhra.we-have-a-problem.com) desde el propio servicio o un programa compilado con la misma versión: la conexión debe fallar por certificado.
Preguntas frecuentes
¿Basta con actualizar Go en el servidor?
No. Un binario de Go no usa el Go instalado en el servidor; lleva su propia copia de la biblioteca estándar. Solo un binario recompilado incorpora el bloqueo.
¿Afecta a programas que no hacen conexiones HTTPS salientes?
El bloqueo protege a Go cuando actúa como cliente TLS o verifica certificados. Un servicio que solo recibe conexiones con su propio certificado no cambia, aunque conviene recompilarlo igual por las correcciones del 8 de octubre.
Fuentes
- Go, historial de versiones.
- oss-security, anuncio de Go 1.27.3 y 1.26.10.
- GitHub, golang/go#82345.
- Red Hat, RHSB-2026-012.
- Contexto del incidente: certificados de eMudhra comprometidos.
Apoyo para recompilar y redesplegar
Xterra Engine actualiza cadenas de compilación de Go, imágenes y despliegues, y deja verificado qué versión lleva cada binario en producción. Para solicitar apoyo o una cotización, escriba a info@xterraengine.com o use el formulario de contacto.