GoAhead : le mTLS accepte des certificats clients révoqués (CVE-2026-115881)

En bref

GoAhead, un serveur web embarqué que son éditeur dit présent dans des centaines de millions d'équipements, ignore silencieusement la liste de révocation de certificats qu'il est configuré pour appliquer.

• Le backend TLS OpenSSL de GoAhead charge la CRL configurée dans le magasin de certificats mais n'active jamais X509_V_FLAG_CRL_CHECK, l'indicateur qu'OpenSSL exige avant de consulter la liste. Un certificat client révoqué complète le handshake mTLS exactement comme s'il était valide. 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), noté par EmbedThis ; affecte GoAhead 3.4.5 à 6.1.0.
• Deux autres failles TLS accompagnent la même analyse. Sur les builds avec le vérificateur historique de LibreSSL, une chaîne de certificats plus longue que la limite de 10 est acceptée quand la vérification d'émetteur est désactivée (CVE-2026-115884, 7,4).
• Sur les builds Mbed TLS, un paramètre Diffie-Hellman d'un octet rend des sessions TLS 1.2 DHE_RSA déchiffrables par un observateur passif (5,9, pas de CVE).
• La version 6.1.1 corrige aussi un contournement de connexion où l'authentification HTTP Basic et par formulaire accepte n'importe quel mot de passe pour les utilisateurs au format Blowfish (CVE-2026-115888, 9,8, uniquement 6.1.0).
• GoAhead 6.1.1, livrée aux fabricants d'équipements le 2 août 2026, corrige tout cela ; ses onze avis ont été publiés le 12 octobre. Aucune attaque n'est signalée au 27 octobre, et on ne sait si un fabricant a déjà livré le correctif.
• Les propriétaires d'équipements n'obtiennent le correctif que lorsque leur fabricant publie une mise à jour de firmware. D'ici là : identifiez vos équipements GoAhead et, sur les builds affectés, restreignez l'accès de gestion aux réseaux de confiance.

Suis-je concerné ?

L'exposition dépend du backend TLS et des réglages compilés dans l'équipement, que le propriétaire ne peut pas lire de l'extérieur. Vous êtes concerné par la faille CRL si toutes ces conditions sont réunies :

• Le firmware embarque GoAhead 3.4.5 à 6.1.0, compilé avec le backend OpenSSL (ME_COM_OPENSSL=1, le backend par défaut et préféré du projet). Les builds Mbed TLS ne sont pas affectés ; ils vérifient la révocation par un chemin séparé.
• Le mTLS est activé : ME_GOAHEAD_SSL_VERIFY_PEER=1, un bundle d'AC de confiance (ME_GOAHEAD_SSL_AUTHORITY), la vérification d'émetteur (ME_GOAHEAD_SSL_VERIFY_ISSUER=1) et une liste de révocation configurée (ME_GOAHEAD_SSL_REVOKE).
• L'exploitant compte sur la CRL pour refuser les équipements révoqués, ce qui est tout l'intérêt de la configurer.

Pour trouver les serveurs GoAhead dans votre parc, utilisez les empreintes JA4Scan-TLS publiées par FoxIO pour GoAhead 6.1.x :

Une correspondance désigne GoAhead 6.1.x sur ces versions de bibliothèque ; une absence de correspondance n'exclut ni les versions antérieures de GoAhead ni d'autres builds.

Pour la faille DH de Mbed TLS, vérifiez si vos journaux de session TLS (JA4S) contiennent une suite DHE_RSA. L'exemple de FoxIO est t120100_009f_1ca028f07214 ; la commande ci-dessous couvre les 25 codes de suites DHE_RSA listés dans son analyse, en majuscules comme en minuscules :

# 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

Pour un firmware que vous possédez ou construisez, la vérification qui fait autorité est la configuration de build du firmware et la version de GoAhead qu'elle contient, pas la vue externe.

Comment corriger le problème ?

Passez à GoAhead 6.1.1, qui corrige les onze avis et ne laisse plus aucun constat Critique ou Élevé ouvert, selon ses notes de version. Les fabricants d'équipements recompilent leur firmware dessus et livrent la mise à jour ; un propriétaire ne la reçoit que par cette mise à jour. Après la mise à niveau, EmbedThis recommande de terminer les sessions actives ou de redémarrer le serveur, et de changer les mots de passe des utilisateurs BF1.

Si vous ne pouvez pas encore recompiler, chaque faille a une mesure intermédiaire partielle :

• Pour la faille de profondeur LibreSSL, activez la vérification d'émetteur (ME_GOAHEAD_SSL_VERIFY_ISSUER=1) avec un bundle d'AC de confiance, ou compilez avec OpenSSL ou LibreSSL 4.x.
• Pour la faille DH de Mbed TLS, désactivez les suites DHE en champ fini pour ne négocier que l'ECDHE et TLS 1.3, ou passez au backend OpenSSL.
• Pour la faille CRL, l'avis ne donne pas d'option intermédiaire : jusqu'à la recompilation, considérez chaque identifiant d'équipement autrefois approuvé et désormais révoqué comme encore valide, et compensez au niveau réseau en restreignant les sources pouvant joindre l'interface de gestion.
• Pour le contournement BF1, un attaquant n'a besoin que d'un nom d'utilisateur valide : faites passer les mots de passe BF1 à un autre format quand c'est possible, et surveillez les journaux d'authentification de ces utilisateurs.

Quelle est la cause profonde ?

Les trois failles TLS sont des défauts d'intégration : GoAhead appelle l'API de la bibliothèque TLS d'une façon qui semble configurée mais n'est pas appliquée.

La faille CRL (CVE-2026-115881). Dans sslOpen() de src/openssl.c, GoAhead charge la liste de révocation configurée dans le magasin de certificats 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() réussit et le démarrage n'émet aucune erreur, donc un opérateur qui a configuré une CRL a toutes les raisons de croire la révocation appliquée. Mais OpenSSL exige l'indicateur X509_V_FLAG_CRL_CHECK avant que son check_revocation() consulte la liste, et GoAhead ne l'active jamais. Sans l'indicateur, la vérification d'OpenSSL renvoie succès sans lire la liste :

// 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 a démontré le résultat sur GoAhead 6.1.0 avec OpenSSL 3.6.2 : un certificat client révoqué signé par une AC complétait le handshake mTLS avec la vérification d'émetteur activée, et le rappel de vérification rapportait l'erreur 0 sur toute la chaîne.

La faille DH de Mbed TLS. Dans src/mbedtls.c, GoAhead configure le groupe Diffie-Hellman RFC 3526 de 2048 bits, mais passe la longueur du générateur comme longueur de module :

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) vaut un octet, donc Mbed TLS ne lit que le premier octet du module, 0xFF. Le ServerKeyExchange annonce un paramètre DH d'un octet de valeur 255. Huit valeurs de secret partagé seulement sont possibles, et un observateur peut essayer chacune contre le trafic enregistré ; FoxIO a reproduit le secret partagé après cinq tentatives et déchiffré la session hors ligne. La coquille est entrée en 2018, lors de la migration vers l'API à paramètres binaires, et a survécu à la refonte TLS d'avril 2024. Le client OpenSSL testé a refusé les paramètres avec DH_check_params_ex: modulus too small ; les clients permissifs sans vérification de taille minimale les acceptent.

La faille de profondeur LibreSSL (CVE-2026-115884). GoAhead fixe une limite de 10 certificats avec SSL_CTX_set_verify_depth(), et son rappel de vérification n'assigne l'erreur de dépassement que si le vérificateur n'a pas déjà rapporté une autre erreur :

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

Le rappel rejette l'erreur 22, CERT_CHAIN_TOO_LONG, mais tolère l'erreur 20, UNABLE_TO_GET_ISSUER_CERT_LOCALLY, quand la vérification d'émetteur est désactivée. Le vérificateur historique de LibreSSL 3.2.x et 3.3.2-3.3.6 arrête la construction d'une chaîne trop profonde sans enregistrer l'erreur de profondeur, et rapporte l'erreur 20 tolérée. Sur GoAhead 6.1.0 avec LibreSSL 3.3.6, une chaîne de 17 certificats enracinée dans une AC auto-signée contrôlée par l'attaquant a complété le handshake et reçu un HTTP 200 ; la même source contre LibreSSL 4.3.1 a rapporté l'erreur 22 et été rejetée.

Le contournement de connexion BF1 (CVE-2026-115888), un compagnon corrigé dans la même version. Dans websVerifyPasswordFromFile(), la branche BF1 calcule correctement le résultat bcrypt, le stocke dans une variable locale, puis écrase l'identifiant soumis avec le hachage stocké pour que le comparateur à temps constant partagé de la fonction compare le hachage stocké à lui-même. N'importe quel mot de passe est accepté pour un utilisateur dont le mot de passe est au format Blowfish (BF1:) plus récent ; la connexion par formulaire est le schéma recommandé et la valeur par défaut des pages d'administration intégrées de GoAhead.

Comment la faille est-elle exploitée ?

La faille CRL n'exige aucun outil nouveau : l'attaquant présente un certificat valablement émis et désormais révoqué, par exemple l'identifiant d'un équipement volé, retiré ou compromis, et complète le handshake mTLS sous cette identité. Rien de l'attaque n'est visible, car la vérification du serveur elle-même rapporte un succès.

La faille Mbed TLS est passive. Un observateur ayant enregistré une session TLS 1.2 DHE_RSA, où le client a accepté le paramètre d'un octet, essaie les huit valeurs possibles de secret partagé contre le handshake et les enregistrements applicatifs, identifie celle qui déchiffre et lit la session. Aucune interaction avec le serveur n'est nécessaire après la capture.

La faille LibreSSL exige une chaîne de certificats forgée : plus de 10 certificats, enracinée n'importe où, présentée à un build avec certificats clients exigés et vérification d'émetteur désactivée. La chaîne est acceptée comme client authentifié.

Le contournement BF1 n'exige qu'un nom d'utilisateur connu ou deviné dont le mot de passe est au format BF1, et une chaîne de mot de passe quelconque, contre une URL en Basic auth ou un formulaire de connexion.

Comment se déroule la chaîne d'attaque ?

La faille CRL, d'un identifiant d'équipement révoqué à un accès autorisé, en quatre étapes :

Que peut faire un attaquant ?

La faille CRL rend l'accès à tout ce que l'identifiant d'équipement révoqué autorisait : les pages de gestion, les API ou les commandes d'équipement que ce certificat protégeait. Elle importe le plus aux déploiements qui révoquent délibérément, par exemple après un vol d'équipement ou une compromission de clé, et l'écart est invisible côté serveur, qui journalise une vérification réussie.

La faille Mbed TLS rend des sessions enregistrées lisibles, y compris les identifiants ou commandes qu'elles transportent, mais seulement si le client a accepté les paramètres défectueux : les clients standards refusent un module d'un octet et ne complètent jamais une telle session. Les clients personnalisés et embarqués sans contrôle de taille minimale sont la population exposée. Les sessions ECDHE et TLS 1.3 ne sont pas affectées.

La faille LibreSSL authentifie un attaquant comme client sans aucune clé de confiance, mais uniquement sur les builds LibreSSL historiques listés avec vérification d'émetteur désactivée, une configuration qui accepte déjà les clients auto-signés ; les déploiements exigeant une AC cliente de confiance la rejettent.

Le contournement BF1 connecte un attaquant à l'interface d'administration de l'équipement avec les privilèges de l'utilisateur visé. Il n'affecte que GoAhead 6.1.0, publiée le 3 novembre 2025, et seulement les utilisateurs dont les mots de passe ont été migrés au format BF1.

Pourquoi le correctif fonctionne-t-il ?

Les correctifs CRL et DH sont des corrections d'une ligne, et chaque correctif de 6.1.1 ferme complètement sa faille au lieu de la réduire. Pour la faille CRL, le magasin est maintenant marqué juste après le chargement de la liste :

     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);

Pour la faille DH, la longueur du module est maintenant la longueur du module lui-même :

- 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) {

Avec le module complet de 2048 bits transmis, le secret partagé n'est plus l'un de huit candidats et les sessions enregistrées ne sont plus forcibles. Pour la faille de profondeur LibreSSL, 6.1.1 applique la limite de profondeur sans condition, avant tout contrôle du code d'erreur, si bien qu'une chaîne trop profonde est rejetée quelle que soit l'erreur rapportée par le vérificateur ; FoxIO a vérifié que la même source contre LibreSSL 4.3.1 rapportait déjà l'erreur 22 et rejetait la chaîne de 17 certificats.

Pour le contournement BF1, le correctif de l'avis découpe websVerifyPasswordFromFile() en trois branches distinctes, chacune fixant le résultat une seule fois, et n'écrase plus le mot de passe soumis avec le hachage stocké :

• Pour les utilisateurs BF1, le résultat bcrypt est définitif.
• Pour l'authentification Digest, le condensé du client est comparé au hachage stocké.
• Pour les utilisateurs au format MD5 historique, le mot de passe encodé est comparé en temps constant.

Les notes de version ajoutent un durcissement lié issu du même audit interne, qui a résolu onze avis et 31 autres constats internes : les hachages BF1 combinés à l'authentification Digest sont désormais explicitement rejetés, et les identifiants de session sont renouvelés à chaque connexion.

Comment vérifier si j'ai été compromis ?

Aucun indicateur d'attaque n'est publié, car aucune attaque n'est signalée. Vérifiez plutôt les conséquences :

• Pour la faille CRL, comparez les certificats clients qui se sont authentifiés sur chaque serveur GoAhead depuis son déploiement au contenu actuel de la CRL. Tout certificat de la liste de révocation encore authentifié après sa date de révocation signifie que la faille vous a concerné, côté serveur ou dans vos journaux d'accès.
• Pour la faille Mbed TLS, cherchez dans le trafic enregistré les handshakes TLS 1.2 DHE_RSA portant un paramètre DH d'un octet, les octets ServerKeyExchange 00 01 ff, et considérez ces sessions comme déchiffrables ; la liste de suites JA4S de FoxIO restreint la recherche.
• Pour le contournement BF1, passez en revue les journaux d'authentification des équipements 6.1.0 pour des connexions réussies d'utilisateurs BF1 depuis des sources inattendues, et considérez ces identifiants comme capturés.

Chronologie

• 2018 : la coquille de longueur DH de Mbed TLS entre lors de la migration vers l'API à paramètres binaires, selon l'historique de code de FoxIO ; elle survit à la refonte TLS d'avril 2024.
• 2025-11-03 : GoAhead 6.1.0 est publiée ; le contournement de connexion BF1 est introduit avec son nouveau format de mot de passe.
• 2026-08-02 : GoAhead 6.1.1, une version de sécurité fermant onze avis et 31 autres constats d'audit, est livrée aux fabricants d'équipements.
• 2026-10-12 : EmbedThis publie les onze avis, avec des CVE demandés ; au 27 octobre, ils n'étaient pas encore dans les bases CVE et NVD publiques.
• 2026-10-26 : FoxIO publie l'analyse des trois failles TLS avec du code de preuve de concept et les empreintes JA4Scan.
• 2026-10-27 : Alan Coopersmith relaie sur oss-security les trois failles TLS de FoxIO et leurs avis ; The Hacker News rapporte qu'aucune attaque n'est connue, cohérent avec la politique d'EmbedThis de publier tôt si une faille est exploitée.
• 2026-10-29 : cet article.

FAQ

Mon équipement n'a pas reçu de mise à jour de firmware. Que puis-je faire aujourd'hui ?

Vous ne pouvez pas recompiler le firmware d'autrui. Identifiez vos équipements GoAhead, confirmez auprès du fabricant si leur build est affecté et quand il livrera 6.1.1, et d'ici là restreignez l'accès de gestion aux réseaux de confiance pour que les vérifications TLS défectueuses ne soient pas la seule barrière. Pour la faille Mbed TLS, désactiver les suites DHE n'est possible que dans votre propre build.

Les clients standards sont-ils affectés par la faille Diffie-Hellman ?

Non. Le client OpenSSL testé par FoxIO a refusé le module d'un octet, et Go, Java et les navigateurs standards actuels le refusent aussi, donc la session ne se complète jamais. Les clients personnalisés et embarqués sans contrôle de taille minimale sont la population exposée, et enregistrer leur trafic suffit pour le déchiffrer plus tard.

Comment savoir quel backend TLS un équipement utilise ?

De l'extérieur, vous ne pouvez pas ; le backend et les réglages de vérification sont des choix de compilation. Les empreintes JA4Scan de FoxIO identifient le backend des serveurs GoAhead joignables sur internet, et la configuration de build de votre propre firmware est la réponse qui fait autorité.

Quelqu'un a-t-il été attaqué ?

Aucune source ne rapportait d'attaque au 27 octobre 2026. La politique de divulgation d'EmbedThis est de lever l'embargo et de publier tôt si une faille est exploitée ou divulguée par autrui, donc la publication coordonnée du 12 octobre est cohérente avec l'absence d'attaques connues ; cela ne prouve pas qu'il n'y en a pas, et la population affectée n'est pas établie.

6.1.1 corrige-t-il autre chose d'important ?

Oui. La version ferme onze avis au total, dont une injection de commandes CGI Windows via cibles .bat et .cmd (9,8, pas encore de CVE), une injection d'arguments CGI ISINDEX (CVE-2026-115880, 8,1), une injection HTTP_PROXY de type httpoxy (CVE-2026-115882, 8,1), deux vecteurs de smuggling de requêtes HTTP, une divulgation du masterSecret dans les nonces Digest et une fixation de session, plus 31 défauts trouvés en interne, chacun avec un test de non-régression.

Repérez les équipements GoAhead avec Ostorlab

Utilisez Ostorlab Attack Surface Discovery pour inventorier les hôtes exposés à internet que vous possédez, afin que les équipements GoAhead parmi eux, leurs interfaces de gestion et leurs empreintes TLS soient connus avant d'attendre la mise à jour du fabricant.

Références

• FoxIO, Sébastien Féry, « Choose Your Backend: Three TLS Bugs in GoAhead », 26 octobre 2026 : les trois causes profondes avec citations du code source, les traces du rappel de vérification, les octets ServerKeyExchange, les empreintes JA4Scan et la liste des suites DHE_RSA : https://foxio.io/blog/choose-your-backend-three-tls-bugs-in-goahead (consulté le 29 octobre 2026)
• Avis de sécurité EmbedThis GoAhead, publiés le 12 octobre 2026 : GHSA-5m75-xq69-c3c5 (CRL OpenSSL non appliquée, CVE-2026-115881, 9,1, GoAhead 3.4.5 à 6.1.0) : https://github.com/embedthis/goahead/security/advisories/GHSA-5m75-xq69-c3c5 (consulté le 29 octobre 2026)
• GHSA-r392-vqwx-3r4g, contournement de la limite de profondeur de chaîne du certificat client mTLS sur les builds avec vérificateur historique LibreSSL, CVE-2026-115884, 7,4 : https://github.com/embedthis/goahead/security/advisories/GHSA-r392-vqwx-3r4g (consulté le 29 octobre 2026)
• GHSA-fmvx-2xfx-2gq4, troncature du paramètre DH MbedTLS, 5,9, pas de CVE attribué : https://github.com/embedthis/goahead/security/advisories/GHSA-fmvx-2xfx-2gq4 (consulté le 29 octobre 2026)
• GHSA-qj3g-66fp-rhhr, contournement d'authentification pour les utilisateurs au hachage BF1, CVE-2026-115888, 9,8, uniquement GoAhead 6.1.0, corrigé dans 6.1.1 : https://github.com/embedthis/goahead/security/advisories/GHSA-qj3g-66fp-rhhr (consulté le 29 octobre 2026)
• Notes de version GoAhead v6.1.1 : livrée aux fabricants le 2 août 2026, avis publiés le 12 octobre 2026 ; onze avis et 31 correctifs supplémentaires résolus, plus aucun constat Critique ou Élevé ouvert : https://github.com/embedthis/goahead/releases/tag/v6.1.1 (consulté le 29 octobre 2026)
• Les autres avis 6.1.1, dont l'injection de commandes CGI Windows (GHSA-584w-ph2x-4gfq, 9,8), l'injection CGI ISINDEX (GHSA-c7w3-26wq-mjc3, CVE-2026-115880, 8,1) et l'injection HTTP_PROXY (GHSA-w3p3-6x8p-vrjr, CVE-2026-115882, 8,1) : https://github.com/embedthis/goahead/security/advisories (consulté le 29 octobre 2026)
• Alan Coopersmith sur oss-security, « Three TLS Bugs in GoAhead web server prior to 6.1.1 », 27 octobre 2026 (message daté du 27 octobre 2026 17:17 UTC-7, archivé au 28 octobre) : https://www.openwall.com/lists/oss-security/2026/10/28/1 (consulté le 29 octobre 2026)
• The Hacker News, « GoAhead TLS Flaws Allow Revoked Client Certificates and Enable Session Decryption », 27 octobre 2026 : le statut sans attaque connue, la politique de divulgation d'EmbedThis, le retard des bases CVE et les recommandations après mise à niveau : https://thehackernews.com/2026/10/goahead-tls-flaws-allow-revoked-client.html (consulté le 29 octobre 2026)