Fallos en GoAhead TLS aceptan silenciosamente certificados revocados y debilitan el cifrado

EmbedThis lanzó la versión 6.1.1 de GoAhead el 12 de octubre de 2026 para abordar fallos de seguridad críticos en su ampliamente utilizado servidor web embebido. La actualización corrige problemas que permitían que los certificados de cliente revocados pasaran la autenticación y debilitaban el cifrado en ciertas compilaciones TLS, afectando potencialmente a cientos de millones de dispositivos IoT.

Qué ocurrió

La vulnerabilidad principal, identificada como CVE-2026-115881 con una severidad calificada por el proveedor de 9.1, afecta a las compilaciones de GoAhead que utilizan el backend OpenSSL con TLS mutuo habilitado. En estas configuraciones, el servidor carga una lista de revocación de certificados al iniciarse, pero no la hace cumplir. Como consecuencia, los clientes que presentan certificados revocados, como los de dispositivos robados o retirados, son aceptados silenciosamente como válidos. Este fallo existe en las versiones 3.4.5 a 6.1.0 cuando la configuración del operador incluye un paquete de autoridad certificadora de confianza, verificación del emisor y una lista de revocación.

El investigador Sébastien Féry de FoxIO divulgó este problema junto con otros dos relacionados con TLS el 26 de octubre de 2026. Aunque la corrección se proporcionó a los fabricantes de dispositivos el 2 de agosto de 2026, la divulgación pública siguió en octubre. EmbedThis afirma que no se ha reportado explotación activa, aunque el momento coordinado de la publicación sugiere que no había ataques conocidos en curso en el momento de la publicación.

Se abordaron dos vulnerabilidades adicionales en la misma versión. Una afecta a las compilaciones que usan versiones antiguas de LibreSSL (3.2.x y 3.3.2–3.3.6), permitiendo que cadenas de certificados que superan el límite de diez certificados eludan la validación cuando la verificación del emisor está deshabilitada. La otra impacta a las compilaciones de Mbed TLS (versiones 4.0.2 a 6.1.0), donde un error de codificación hace que el servidor envíe un valor Diffie-Hellman de un byte en lugar del valor de 2048 bits previsto. Esta debilidad permite a observadores pasivos descifrar sesiones si el cliente acepta el intercambio de clave malformado.

Cómo funciona

El fallo de OpenSSL surge de un error lógico donde la lista de revocación se carga en memoria pero nunca se consulta activamente durante el proceso de handshake. El servidor no reporta errores durante el inicio, dando a los operadores una falsa sensación de seguridad. Cuando un cliente presenta un certificado, el servidor valida su firma contra la autoridad de confianza pero omite el paso de verificar si ese número de serie específico aparece en la lista de revocación. Esto permite que cualquier certificado firmado por una autoridad de confianza otorgue acceso, independientemente de su estado de revocación.

El problema de Mbed TLS implica un error tipográfico en el código que maneja los intercambios de clave Diffie-Hellman de campo finito. En lugar de transmitir un valor público robusto de 2048 bits, el servidor envía un solo byte. Los clientes convencionales como navegadores modernos, Java y Go rechazan este valor pequeño y abortan la conexión. Sin embargo, los clientes embebidos o personalizados que carecen de comprobaciones de tamaño mínimo pueden aceptarlo, estableciendo una clave de sesión débil que un espía puede calcular fácilmente. Esta vulnerabilidad no afecta a las sesiones TLS 1.3 o ECDHE.

Detalles clave

• CVE-2026-115881: Calificada con 9.1, afecta a compilaciones de OpenSSL 3.4.5–6.1.0 con TLS mutuo y listas de revocación configuradas; se aceptan certificados revocados.
• CVE-2026-115884: Calificada con 7.4, afecta a compilaciones de LibreSSL 3.2.x y 3.3.2–3.3.6; permite cadenas de certificados demasiado largas cuando la verificación del emisor está apagada.
• Fallo de Mbed TLS: Calificado con 5.9, afecta a las versiones 4.0.2–6.1.0; envía valores Diffie-Hellman de 1 byte, habilitando el descifrado de sesiones por observadores pasivos.
• Disponibilidad de la corrección: GoAhead 6.1.1 resuelve todos los problemas; los propietarios de dispositivos deben esperar a que los fabricantes lancen actualizaciones de firmware que contengan esta versión.
• Corrección adicional: La versión 6.1.1 también parchea una elusión de inicio de sesión que permite el acceso con cualquier contraseña si el nombre de usuario es conocido y está almacenado en formato Blowfish.
• Detección: FoxIO ofrece huellas digitales de la herramienta JA4Scan para identificar backends de GoAhead, aunque esto identifica el tipo de compilación más que una vulnerabilidad confirmada.

Por qué importa

Para los ingenieros que gestionan infraestructura IoT, este incidente destaca la opacidad de las cadenas de suministro de software embebido. GoAhead se ejecuta en routers, impresoras y controladores industriales de grandes proveedores como HP, Siemens y D-Link. Debido a que el backend TLS y la configuración se compilan dentro del firmware, los propietarios de dispositivos no pueden determinar su exposición sin una inspección profunda o la confirmación del proveedor. El retraso entre la liberación de la corrección a los fabricantes en agosto y la divulgación pública en octubre subraya el lento ciclo de parcheo típico de los dispositivos embebidos, dejando los sistemas vulnerables durante períodos prolongados.

El fallo silencioso de la verificación de revocación es particularmente peligroso para entornos que dependen de TLS mutuo para la autenticación de dispositivos. Los operadores que configuran explícitamente listas de revocación para gestionar la seguridad del ciclo de vida del dispositivo son inducidos a creer que sus controles están activos. Esto socava la confianza en los mecanismos de autenticación basados en certificados, que suelen ser la defensa principal para dispositivos headless que carecen de interfaces de usuario tradicionales. La presencia de una elusión de inicio de sesión en la misma versión agrava aún más el riesgo, sugiriendo que múltiples capas de defensa pueden verse comprometidas simultáneamente.

Qué puedes hacer

• Identifica los dispositivos que ejecutan GoAhead en tu entorno y contacta a los fabricantes para confirmar si han lanzado firmware basado en la versión 6.1.1.
• Si controlas el proceso de compilación del firmware, actualiza inmediatamente a GoAhead 6.1.1 y reconstruye tus imágenes.
• Para las compilaciones de Mbed TLS, deshabilita los suites DHE de campo finito o cambia al backend OpenSSL como mitigación provisional antes de actualizar.
• Para las compilaciones de LibreSSL, habilita la verificación del emisor con un paquete CA de confianza o actualiza a LibreSSL 4.x si es posible.
• Después de actualizar, finaliza todas las sesiones activas, reinicia el servidor y rota cualquier contraseña almacenada en formato Blowfish.
• Usa herramientas como JA4Scan para identificar instancias de GoAhead y determinar qué backend TLS utilizan, ayudando a priorizar los esfuerzos de remediación.