Go bloquea 8 certificados TLS por CVE-2026-111943

Go bloquea ocho certificados intermedios por CVE-2026-111943

El equipo de Go cerró el issue #82345 con una medida poco habitual: crypto/x509 ahora descarta las cadenas de certificados que contengan un conjunto reducido de intermedios, de modo que Verify no las devuelva nunca al llamador. El cambio está etiquetado como release-blocker y apunta al hito Go 1.28, con backports abiertos para las ramas 1.26 y 1.27.

Para un founder, la traducción es directa: si tu backend, tu API o tu worker en Go valida certificados TLS contra una CA pública, esta actualización puede cambiar de golpe qué conexiones considera válidas. No es una mejora de rendimiento ni una feature nueva: es un parche de seguridad con recomendación explícita de actualizar de inmediato.

¿Qué pasó exactamente con los certificados de Go?

El issue, abierto el 19 de octubre de 2026 por thatnealpatel, describe la medida en dos frases: se bloquea la confianza en un conjunto pequeño de certificados intermedios «debido a preocupaciones de seguridad específicas alrededor de su operación», y Verify filtra las cadenas que los contienen para que no lleguen al llamador.

El identificador es CVE-2026-111943 y el caso se tramitó por la vía Urgent de la política de seguridad de Go, originalmente seguido en un bug interno de Google. El issue pasó de titularse «security: fix CVE-2026-111943» a «crypto/x509: mitigation for security concerns with a specific Certificate Authority», lo que confirma que el problema no está en el código de Go sino en una autoridad certificadora.

En el hilo, el colaborador zhangyoufu publicó los ocho hashes SPKI afectados junto con sus enlaces de verificación en Censys. Los sujetos corresponden a intermedios de eMudhra BV (Países Bajos) y eMudhra Inc (Estados Unidos), todos emitidos por raíces emSign Root TLS CA – G3 y emSign Root CS CA – G3 de eMudhra Technologies Limited (India). Son ocho variantes: DV, EV, OV y OV CS, cada una en versión G3B y G3C.

Otro comentario, de x0wllaar, aporta el dato más relevante del hilo: los certificados ya habían sido revocados por cACompromise el 18 y 19 de octubre según el registro público CCADB, y añade que no había noticias ni reportes al respecto en ningún medio. Las búsquedas realizadas para esta nota no arrojaron cobertura periodística adicional verificable fuera del hilo oficial.

¿Por qué importa una revocación por cACompromise?

cACompromise es la razón de revocación más grave que existe en la infraestructura de certificados: significa que la autoridad emisora perdió el control de su clave privada, o que hay evidencia de que un tercero puede emitir certificados en su nombre. Cuando eso ocurre, cualquier certificado emitido bajo esa jerarquía deja de ser confiable, porque un atacante podría haber creado certificados válidos para dominios que no le pertenecen.

Ahí está el riesgo concreto para un negocio: un certificado fraudulento emitido por un intermedio comprometido permite montar un sitio idéntico al tuyo, interceptar tráfico o firmar código. Es la base técnica del phishing que sí engaña al navegador.

Lo llamativo del caso es la asimetría de información. La revocación está en el registro público, pero según el propio hilo no hubo anuncio ni cobertura. Eso deja a los equipos de ingeniería con una única señal de que algo pasó: el parche de Go.

¿Qué cambia en crypto/x509 y a quién afecta?

El cambio es quirúrgico: no se desconfía de la raíz completa, sino de un puñado de intermedios. Verify sigue funcionando igual para todo lo demás, pero cuando arma la cadena y detecta uno de esos SPKI, descarta esa cadena y no la devuelve.

Consecuencias prácticas:

• Si tu servicio en Go se conecta a un sitio cuyo certificado cuelga de uno de esos intermedios, la validación fallará con error de certificado desconocido. No es un bug: es el comportamiento deseado.
• Si eres tú quien usa un certificado emitido por esa jerarquía, tus clientes que actualicen Go dejarán de poder conectarse.
• Si tienes pinning o una lista de CAs permitidas, revisa que no estés confiando en una jerarquía que el ecosistema está dejando de aceptar.

Las ramas con backport abierto son 1.26 (#82348) y 1.27 (#82349), y el hito principal es Go 1.28. En el mismo hilo, commits de proyectos de terceros registran actualizaciones a Go 1.27.3 y Go 1.26.10 para cubrir el CVE, lo que da una idea de las versiones de parche que están saliendo.

¿Qué significa esto para tu startup?

Tres movimientos concretos, en orden de urgencia:

1. Actualiza Go hoy, no en el próximo sprint. El propio issue recomienda actualizar inmediatamente a esta release. Si tu producto corre en 1.26 o 1.27, agenda el bump de versión como tarea de seguridad, no como deuda técnica acumulada.
2. Audita de dónde vienen tus certificados TLS. Revisa la cadena completa de tus dominios, no solo el certificado final. Si algún intermedio de tu cadena pertenece a esa jerarquía, tus usuarios con Go actualizado van a ver errores de conexión y tú vas a ver caídas de tráfico. Migrar de emisor es más barato que perder conversiones.
3. Instrumenta el error de validación. Añade alertas sobre fallos de handshake TLS en tus servicios. Un cambio de confianza en el ecosistema se manifiesta primero como un pico de errores de certificado, y detectarlo en minutos en lugar de días es la diferencia entre un incidente y un apagón.

Y una lección de proceso para founders técnicos: la revocación llevaba días en el registro público y, según el hilo, nadie la había reportado. Si tu equipo solo se entera de los problemas de PKI cuando un parche aparece en un changelog, te falta un canal de monitoreo de infraestructura de confianza.

Conclusión

Go no está arreglando un bug suyo: está reaccionando a un problema de confianza en una CA y protegiendo a sus usuarios por defecto. Ocho SPKI intermedios quedan fuera, y quien no actualice se queda con la versión que todavía confía en ellos.

Para una startup, el costo de actualizar es un par de horas de CI. El costo de no hacerlo puede ser un cliente que no logra conectarse a tu API, o peor, un certificado falso a nombre de tu dominio circulando sin que nadie lo note. La decisión es fácil.

Fuentes

• https://github.com/golang/go/issues/82345 (fuente original)

Artículos relacionados:

Google detecta certificados TLS falsos emitidos a su nombre Let’s Encrypt detiene emisión: qué hacer con tu SSL hoy Let’s Encrypt caído hoy: qué hacer si tu SSL expira Cloudflare: 650K dominios ya no reciben spam de alertas TLS en 2026 Let’s Encrypt reduce a 64 días los certificados TLS en 2027