GoAhead: el mTLS acepta certificados de cliente revocados (CVE-2026-115881)

Resumen

GoAhead, un servidor web embebido que su fabricante dice presente en cientos de millones de dispositivos, ignora en silencio la lista de revocación de certificados que está configurado para aplicar.

• El backend TLS de OpenSSL de GoAhead carga la CRL configurada en el almacén de certificados pero nunca activa X509_V_FLAG_CRL_CHECK, el indicador que OpenSSL exige antes de consultar la lista. Un certificado de cliente revocado completa el handshake mTLS exactamente como si fuera válido. CVE-2026-115881, CVSS v3.1 9.1 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N), valorado por EmbedThis; afecta a GoAhead 3.4.5 a 6.1.0.
• Dos fallos TLS más acompañan el mismo análisis. En compilaciones con el verificador heredado de LibreSSL, se acepta una cadena de certificados más larga que el límite de 10 cuando la comprobación de emisor está desactivada (CVE-2026-115884, 7.4).
• En compilaciones Mbed TLS, un parámetro Diffie-Hellman de un byte hace que un observador pasivo descifre sesiones TLS 1.2 DHE_RSA (5.9, sin CVE).
• La versión 6.1.1 también corrige un rodeo de inicio de sesión donde la autenticación HTTP Basic y por formulario acepta cualquier contraseña para usuarios con hash Blowfish (CVE-2026-115888, 9.8, solo 6.1.0).
• GoAhead 6.1.1, entregada a los fabricantes de dispositivos el 2 de agosto de 2026, corrige todo esto; sus once avisos se publicaron el 12 de octubre. No se reportan ataques al 27 de octubre, y no se sabe si algún fabricante ya entregó el parche.
• Los propietarios de dispositivos obtienen el parche solo cuando su fabricante publica una actualización de firmware. Hasta entonces: identifique sus dispositivos GoAhead y, en las compilaciones afectadas, restrinja el acceso de gestión a redes de confianza.

¿Estoy afectado?

La exposición depende del backend TLS y de los ajustes compilados en el dispositivo, que el propietario no puede leer desde fuera. Está afectado por el fallo de la CRL si se cumplen todas estas condiciones:

• El firmware incorpora GoAhead 3.4.5 a 6.1.0, compilado con el backend OpenSSL (ME_COM_OPENSSL=1, el backend por defecto y preferido del proyecto). Las compilaciones Mbed TLS no están afectadas; comprueban la revocación por una ruta separada.
• El mTLS está activado: ME_GOAHEAD_SSL_VERIFY_PEER=1, un paquete de CA de confianza (ME_GOAHEAD_SSL_AUTHORITY), la verificación del emisor (ME_GOAHEAD_SSL_VERIFY_ISSUER=1) y una lista de revocación configurada (ME_GOAHEAD_SSL_REVOKE).
• El operador confía en la CRL para denegar dispositivos revocados, que es toda la razón de configurarla.

Para encontrar servidores GoAhead en su parque, use las huellas JA4Scan-TLS que FoxIO publicó para GoAhead 6.1.x:

Una coincidencia apunta a GoAhead 6.1.x con esas versiones de la biblioteca; la ausencia de coincidencia no descarta versiones anteriores de GoAhead ni otras compilaciones.

Para el fallo DH de Mbed TLS, compruebe si sus registros de sesión TLS (JA4S) contienen alguna suite DHE_RSA. El ejemplo de FoxIO es t120100_009f_1ca028f07214; el comando siguiente busca los 25 códigos de suites DHE_RSA que enumera su análisis, en mayúsculas o minúsculas:

# Find DHE_RSA handshakes against a host in JA4S session records
grep -iE "_(001[456]|003[39]|0045|006[7b]|0088|009[aef]|00be|00c4|c04[45]|c05[23]|c07[cd]|c09[ef]|c0a[23]|ccaa)_" ja4s.log

Para un firmware que usted posee o compila, la comprobación con autoridad es la configuración de compilación del firmware y la versión de GoAhead que contiene, no la vista externa.

¿Cómo lo corrijo?

Actualice a GoAhead 6.1.1, que corrige los once avisos y no deja ningún hallazgo Crítico o Alto abierto, según sus notas de versión. Los fabricantes de dispositivos recompilan su firmware con ella y entregan la actualización; un propietario la recibe solo por esa vía. Tras actualizar, EmbedThis recomienda cerrar las sesiones activas o reiniciar el servidor, y cambiar las contraseñas de los usuarios BF1.

Si no puede recompilar aún, cada fallo tiene una medida intermedia parcial:

• Para el fallo de profundidad de LibreSSL, active la verificación de emisor (ME_GOAHEAD_SSL_VERIFY_ISSUER=1) con un paquete de CA de confianza, o compile con OpenSSL o LibreSSL 4.x.
• Para el fallo DH de Mbed TLS, desactive las suites DHE de campo finito para negociar solo ECDHE y TLS 1.3, o cambie al backend OpenSSL.
• Para el fallo de la CRL no hay opción intermedia en el aviso: hasta recompilar, considere cada credencial de dispositivo antes confiable y ahora revocada como todavía válida, y compense en la capa de red restringiendo qué fuentes pueden llegar a la interfaz de gestión.
• Para el rodeo BF1, un atacante solo necesita un usuario válido: pase las contraseñas BF1 a otro formato donde pueda y vigile los registros de autenticación de esos usuarios.

¿Cuál es la causa raíz?

Los tres fallos TLS son defectos de integración: GoAhead llama a la API de la biblioteca TLS de una forma que parece configurada pero no se aplica.

El fallo de la CRL (CVE-2026-115881). En sslOpen() de src/openssl.c, GoAhead carga la lista de revocación configurada en el almacén de certificados OpenSSL:

if (ME_GOAHEAD_SSL_REVOKE && *ME_GOAHEAD_SSL_REVOKE) {
    store = SSL_CTX_get_cert_store(sslctx);
    if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {
        error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);
        sslClose();
        return -1;
    }
}

X509_STORE_load_locations() tiene éxito y el arranque no emite error, así que un operador que configuró una CRL tiene todos los motivos para creer que la revocación se aplica. Pero OpenSSL exige el indicador X509_V_FLAG_CRL_CHECK antes de que su check_revocation() consulte la lista, y GoAhead nunca lo activa. Sin el indicador, la comprobación de OpenSSL devuelve éxito sin mirar la lista:

// OpenSSL 3.6.2 crypto/x509/x509_vfy.c, check_revocation()
int crl_check_enabled = (ctx->param->flags & X509_V_FLAG_CRL_CHECK) != 0;
...
if (!crl_check_enabled && !ocsp_check_enabled)
    return 1;

FoxIO demostró el resultado en GoAhead 6.1.0 con OpenSSL 3.6.2: un certificado de cliente revocado y firmado por una CA completó el handshake mTLS con la verificación de emisor activada, y la devolución de verificación informó error 0 en toda la cadena.

El fallo DH de Mbed TLS. En src/mbedtls.c, GoAhead configura el grupo Diffie-Hellman RFC 3526 de 2048 bits, pero pasa la longitud del generador como longitud del módulo:

cuchar dhm_p[] = MBEDTLS_DHM_RFC3526_MODP_2048_P_BIN;  // 256 bytes
cuchar dhm_g[] = MBEDTLS_DHM_RFC3526_MODP_2048_G_BIN; // 1 byte: 0x02
...
if ((rc = mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))) < 0) {

sizeof(dhm_g) vale un byte, así que Mbed TLS solo lee el primer byte del módulo, 0xFF. El ServerKeyExchange anuncia un parámetro DH de un byte con valor 255. Solo ocho valores de secreto compartido son posibles, y un observador puede probar cada uno contra el tráfico registrado; FoxIO reprodujo el secreto compartido tras cinco intentos y descifró la sesión fuera de línea. El error tipográfico entró en 2018, durante la migración a la API de parámetros binarios, y sobrevivió a la refactorización TLS de abril de 2024. El cliente OpenSSL probado rechazó los parámetros con DH_check_params_ex: modulus too small; los clientes permisivos sin comprobación de tamaño mínimo los aceptan.

El fallo de profundidad de LibreSSL (CVE-2026-115884). GoAhead fija un límite de 10 certificados con SSL_CTX_set_verify_depth(), y su devolución de verificación asigna el error de exceso solo cuando el verificador no ha reportado ya otro error:

// src/openssl.c
if (ok && VERIFY_DEPTH < depth) {
    if (error == 0) {
        error = X509_V_ERR_CERT_CHAIN_TOO_LONG;
    }
}

La devolución rechaza el error 22, CERT_CHAIN_TOO_LONG, pero tolera el error 20, UNABLE_TO_GET_ISSUER_CERT_LOCALLY, cuando la verificación de emisor está desactivada. El verificador heredado de LibreSSL 3.2.x y 3.3.2-3.3.6 deja de construir una cadena demasiado profunda sin registrar el error de profundidad, e informa del error 20 tolerado. En GoAhead 6.1.0 con LibreSSL 3.3.6, una cadena de 17 certificados enraizada en una CA auto-firmada controlada por el atacante completó el handshake y recibió un HTTP 200; la misma fuente contra LibreSSL 4.3.1 informó del error 22 y fue rechazada.

El rodeo de inicio BF1 (CVE-2026-115888), un compañero corregido en la misma versión. En websVerifyPasswordFromFile(), la rama BF1 calcula correctamente el resultado bcrypt, lo guarda en una variable local y luego sobrescribe la credencial enviada con el hash almacenado para que el comparador de tiempo constante compartido de la función compare el hash almacenado consigo mismo. Se acepta cualquier contraseña para un usuario cuya contraseña está en el formato Blowfish (BF1:) más reciente; el inicio por formulario es el esquema recomendado y el predeterminado de las páginas de administración integradas de GoAhead.

¿Cómo se explota?

El fallo de la CRL no necesita herramientas nuevas: el atacante presenta un certificado emitido válidamente y ahora revocado, por ejemplo la credencial de un dispositivo robado, retirado o comprometido, y completa el handshake mTLS con esa identidad. Nada del ataque es visible, porque la propia verificación del servidor informa éxito.

El fallo de Mbed TLS es pasivo. Un observador que grabó una sesión TLS 1.2 DHE_RSA, donde el cliente aceptó el parámetro de un byte, prueba los ocho valores posibles de secreto compartido contra el handshake y los registros de aplicación grabados, identifica el que descifra y lee la sesión. No hace falta interacción con el servidor tras la captura.

El fallo de LibreSSL necesita una cadena de certificados manipulada: más de 10 certificados, enraizada donde sea, presentada a una compilación con certificados de cliente exigidos y verificación de emisor desactivada. La cadena se acepta como cliente autenticado.

El rodeo BF1 solo necesita un nombre de usuario conocido o adivinado cuya contraseña esté en formato BF1, y cualquier cadena como contraseña, contra una URL con Basic auth o un formulario de inicio de sesión.

¿Cómo transcurre la cadena de ataque?

El fallo de la CRL, de una credencial de dispositivo revocada a un acceso autorizado, en cuatro pasos:

¿Qué puede hacer un atacante?

El fallo de la CRL devuelve el acceso a lo que la credencial revocada tenía derecho: las páginas de gestión, las API o los controles de dispositivos que ese certificado protegía. Importa más a los despliegues que revocan deliberadamente, por ejemplo tras un robo de dispositivo o una compromisión de clave, y el hueco es invisible en el servidor, que registra una verificación correcta.

El fallo de Mbed TLS hace legibles las sesiones grabadas, incluidas las credenciales o comandos enviados dentro, pero solo donde el cliente aceptó los parámetros rotos: los clientes habituales rechazan un módulo de un byte y nunca completan esa sesión. Los clientes personalizados y embebidos sin comprobación de tamaño mínimo son la población expuesta. Las sesiones ECDHE y TLS 1.3 no están afectadas.

El fallo de LibreSSL autentica a un atacante como cliente sin ninguna clave confiable, pero solo en las compilaciones heredadas de LibreSSL listadas con la verificación de emisor apagada, una configuración que ya acepta clientes auto-firmados; los despliegues que exigen una CA de cliente confiable lo rechazan.

El rodeo BF1 conecta a un atacante a la interfaz de administración del dispositivo con los privilegios del usuario elegido. Solo afecta a GoAhead 6.1.0, publicada el 3 de noviembre de 2025, y solo a usuarios cuyas contraseñas se migraron al formato BF1.

¿Por qué funciona la corrección?

Las correcciones de la CRL y de DH son ajustes de una línea, y cada corrección de 6.1.1 cierra su fallo por completo en lugar de reducirlo. Para el fallo de la CRL, el almacén queda marcado justo después de cargar la lista:

     if (!X509_STORE_load_locations(store, ME_GOAHEAD_SSL_REVOKE, 0)) {
         error("Cannot load certificate revoke list: %s", ME_GOAHEAD_SSL_REVOKE);
         sslClose();
         return -1;
     }
+    /*
+        Enable CRL checking on the leaf certificate. Without this flag OpenSSL loads the CRL but
+        never consults it, silently accepting revoked client certificates.
+     */
+    X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK);

Para el fallo DH, la longitud del módulo pasa a ser la longitud del propio módulo:

- if ((rc = mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_g), dhm_g, sizeof(dhm_g))) < 0) {
+ if ((rc = mbedtls_ssl_conf_dh_param_bin(conf, dhm_p, sizeof(dhm_p), dhm_g, sizeof(dhm_g))) < 0) {

Con el módulo completo de 2048 bits transmitido, el secreto compartido ya no es uno de ocho candidatos y las sesiones grabadas no se pueden forzar. Para el fallo de profundidad de LibreSSL, 6.1.1 aplica el límite de profundidad sin condiciones, antes de comprobar cualquier código de error, de modo que una cadena demasiado profunda se rechaza sea cual sea el error que informe el verificador; FoxIO verificó que la misma fuente contra LibreSSL 4.3.1 ya informaba del error 22 y rechazaba la cadena de 17 certificados.

Para el rodeo BF1, el parche del aviso divide websVerifyPasswordFromFile() en tres ramas separadas, cada una de las cuales fija el resultado una sola vez, y ya no sobrescribe la contraseña enviada con el hash almacenado:

• Para los usuarios BF1, el resultado de bcrypt es definitivo.
• Para la autenticación Digest, el digest del cliente se compara con el hash almacenado.
• Para los usuarios con el formato MD5 heredado, la contraseña codificada se compara en tiempo constante.

Las notas de versión añaden un refuerzo relacionado de la misma auditoría interna, que resolvió once avisos y otros 31 hallazgos internos: los hashes BF1 combinados con autenticación Digest ahora se rechazan explícitamente, y los identificadores de sesión se renuevan en cada inicio de sesión.

¿Cómo compruebo si me comprometieron?

No hay indicadores de ataque publicados, porque no se reportan ataques. Compruebe las consecuencias:

• Para el fallo de la CRL, compare los certificados de cliente que se autenticaron en cada servidor GoAhead desde su despliegue con el contenido actual de la CRL. Cualquier certificado de la lista de revocación que siga autenticándose tras su fecha de revocación significa que el fallo le afectó, del lado del servidor o en sus registros de acceso.
• Para el fallo de Mbed TLS, busque en el tráfico grabado handshakes TLS 1.2 DHE_RSA con un parámetro DH de un byte, los bytes de ServerKeyExchange 00 01 ff, y trate esas sesiones como descifrables; la lista de suites JA4S de FoxIO acota la búsqueda.
• Para el rodeo BF1, revise los registros de autenticación de dispositivos 6.1.0 en busca de inicios de sesión exitosos de usuarios BF1 desde fuentes inesperadas, y trate esas credenciales como capturadas.

Cronología

• 2018: el error tipográfico de longitud DH de Mbed TLS entra durante la migración a la API de parámetros binarios, según la historia de código de FoxIO; sobrevive a la refactorización TLS de abril de 2024.
• 2025-11-03: se publica GoAhead 6.1.0; el rodeo de inicio BF1 se introduce con su nuevo formato de contraseña.
• 2026-08-02: GoAhead 6.1.1, una versión de seguridad que cierra once avisos y otros 31 hallazgos de auditoría, se entrega a los fabricantes de dispositivos.
• 2026-10-12: EmbedThis publica los once avisos, con CVE solicitados; al 27 de octubre aún no estaban en las bases CVE y NVD públicas.
• 2026-10-26: FoxIO publica el análisis de los tres fallos TLS con código de prueba de concepto y las huellas JA4Scan.
• 2026-10-27: Alan Coopersmith difunde en oss-security los tres fallos TLS de FoxIO y sus avisos; The Hacker News reporta que no se conocen ataques, coherente con la política de EmbedThis de publicar pronto si un fallo se está explotando.
• 2026-10-29: esta publicación.

Preguntas frecuentes

Mi dispositivo no ha recibido actualización de firmware. ¿Qué puedo hacer hoy?

No puede recompilar el firmware de otra persona. Identifique sus dispositivos GoAhead, confirme con el fabricante si su compilación está afectada y cuándo entregarán 6.1.1, y hasta entonces restrinja el acceso de gestión a redes de confianza para que las comprobaciones TLS defectuosas no sean la única barrera. Para el fallo de Mbed TLS, desactivar las suites DHE solo es posible en su propia compilación.

¿Los clientes habituales están afectados por el fallo de Diffie-Hellman?

No. El cliente OpenSSL probado por FoxIO rechazó el módulo de un byte, y Go, Java y los navegadores actuales también lo rechazan, así que la sesión nunca se completa. Los clientes personalizados y embebidos sin comprobación de tamaño mínimo son la población expuesta, y grabar su tráfico basta para descifrarlo después.

¿Cómo sé qué backend TLS usa un dispositivo?

Desde fuera, no puede; el backend y los ajustes de verificación son decisiones de compilación. Las huellas JA4Scan de FoxIO identifican el backend de los servidores GoAhead accesibles por internet, y la configuración de compilación de su propio firmware es la respuesta con autoridad.

¿Alguien fue atacado?

Ninguna fuente reportó ataques al 27 de octubre de 2026. La política de divulgación de EmbedThis es terminar el embargo y publicar pronto si un fallo se explota o alguien más lo divulga, así que la publicación coordinada del 12 de octubre es coherente con que no haya ataques conocidos; no prueba que no los haya, y la población afectada no está establecida.

¿Corrige 6.1.1 algo más que deba importarme?

Sí. La versión cierra once avisos en total, incluida una inyección de comandos CGI de Windows mediante objetivos .bat y .cmd (9.8, aún sin CVE), una inyección de argumentos CGI ISINDEX (CVE-2026-115880, 8.1), una inyección HTTP_PROXY de tipo httpoxy (CVE-2026-115882, 8.1), dos vectores de contrabando de peticiones HTTP, una divulgación del masterSecret en los nonces Digest y una fijación de sesión, más 31 defectos internos, cada uno con su test de regresión.

Encuentre dispositivos GoAhead con Ostorlab

Use Ostorlab Attack Surface Discovery para inventariar los hosts expuestos a internet que posee, de modo que los dispositivos GoAhead entre ellos, sus interfaces de gestión y sus huellas TLS sean conocidos antes de esperar la actualización del fabricante.

Referencias

• FoxIO, Sébastien Féry, «Choose Your Backend: Three TLS Bugs in GoAhead», 26 de octubre de 2026: las tres causas raíz con citas del código fuente, las trazas de la devolución de verificación, los bytes del ServerKeyExchange, las huellas JA4Scan y la lista de suites DHE_RSA: https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead (consultado el 29 de octubre de 2026)
• Avisos de seguridad de EmbedThis GoAhead, publicados el 12 de octubre de 2026: GHSA-5m75-xq69-c3c5 (CRL de OpenSSL no aplicada, CVE-2026-115881, 9.1, GoAhead 3.4.5 a 6.1.0): https://github.com/embedthis/goahead/security/advisories/GHSA-5m75-xq69-c3c5 (consultado el 29 de octubre de 2026)
• GHSA-r392-vqwx-3r4g, rodeo de la profundidad de cadena del certificado de cliente mTLS en compilaciones con el verificador heredado de LibreSSL, CVE-2026-115884, 7.4: https://github.com/embedthis/goahead/security/advisories/GHSA-r392-vqwx-3r4g (consultado el 29 de octubre de 2026)
• GHSA-fmvx-2xfx-2gq4, truncamiento del parámetro DH de MbedTLS, 5.9, sin CVE asignado: https://github.com/embedthis/goahead/security/advisories/GHSA-fmvx-2xfx-2gq4 (consultado el 29 de octubre de 2026)
• GHSA-qj3g-66fp-rhhr, rodeo de autenticación para usuarios con hash BF1, CVE-2026-115888, 9.8, solo GoAhead 6.1.0, corregido en 6.1.1: https://github.com/embedthis/goahead/security/advisories/GHSA-qj3g-66fp-rhhr (consultado el 29 de octubre de 2026)
• Notas de versión de GoAhead v6.1.1: entregada a los fabricantes el 2 de agosto de 2026, avisos publicados el 12 de octubre de 2026; once avisos y 31 correcciones adicionales resueltos, ningún hallazgo Crítico o Alto abierto: https://github.com/embedthis/goahead/releases/tag/v6.1.1 (consultado el 29 de octubre de 2026)
• Los demás avisos de 6.1.1, incluida la inyección de comandos CGI de Windows (GHSA-584w-ph2x-4gfq, 9.8), la inyección CGI ISINDEX (GHSA-c7w3-26wq-mjc3, CVE-2026-115880, 8.1) y la inyección HTTP_PROXY (GHSA-w3p3-6x8p-vrjr, CVE-2026-115882, 8.1): https://github.com/embedthis/goahead/security/advisories (consultado el 29 de octubre de 2026)
• Alan Coopersmith en oss-security, «Three TLS Bugs in GoAhead web server prior to 6.1.1», 27 de octubre de 2026 (mensaje fechado el 27 de octubre de 2026 17:17 UTC-7, archivado el 28 de octubre): https://www.openwall.com/lists/oss-security/2026/10/28/1 (consultado el 29 de octubre de 2026)
• The Hacker News, «GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption», 27 de octubre de 2026: el estado sin ataques conocidos, la política de divulgación de EmbedThis, el retraso en las bases CVE y las recomendaciones tras actualizar: https://thehackernews.com/2026/10/goahead-tls-flaws-allow-revoked-client.html (consultado el 29 de octubre de 2026)