Les failles TLS de GoAhead acceptent silencieusement les certificats révoqués et affaiblissent le chiffrement

EmbedThis a publié la version 6.1.1 de GoAhead le 12 octobre 2026 pour corriger des failles de sécurité critiques dans son serveur web embarqué largement utilisé. Cette mise à jour résout des problèmes qui permettaient aux certificats clients révoqués de passer l'authentification et affaiblissaient le chiffrement dans certaines compilations TLS, affectant potentiellement des centaines de millions d'appareils IoT.

Ce qui s'est passé

La principale vulnérabilité, identifiée sous la référence CVE-2026-115881 avec une sévérité évaluée par le fournisseur à 9,1, affecte les compilations de GoAhead utilisant le backend OpenSSL avec le TLS mutuel activé. Dans ces configurations, le serveur charge une liste de révocation de certificats au démarrage mais ne l'applique pas. Par conséquent, les clients présentant des certificats révoqués, tels que ceux provenant d'appareils volés ou retirés du service, sont silencieusement acceptés comme valides. Cette faille existe dans les versions 3.4.5 à 6.1.0 lorsque les paramètres configurés par l'opérateur incluent un bundle d'autorités de certification de confiance, une vérification de l'émetteur et une liste de révocation.

Le chercheur Sébastien Féry de FoxIO a divulgué ce problème ainsi que deux autres problèmes liés à TLS le 26 octobre 2026. Bien que le correctif ait été fourni aux fabricants d'appareils le 2 août 2026, la divulgation publique a suivi en octobre. EmbedThis déclare qu'aucune exploitation active n'a été signalée, bien que le calendrier de la sortie coordonnée suggère qu'aucune attaque connue n'était en cours au moment de la publication.

Deux vulnérabilités supplémentaires ont été corrigées dans la même version. L'une affecte les compilations utilisant d'anciennes versions de LibreSSL (3.2.x et 3.3.2–3.3.6), permettant aux chaînes de certificats dépassant la limite de dix certificats de contourner la validation lorsque la vérification de l'émetteur est désactivée. L'autre impacte les compilations Mbed TLS (versions 4.0.2 à 6.1.0), où une erreur de codage amène le serveur à envoyer une valeur Diffie-Hellman d'un octet au lieu de la valeur prévue de 2048 bits. Cette faiblesse permet aux observateurs passifs de déchiffrer les sessions si le client accepte cet échange de clés malformé.

Comment cela fonctionne

La faille OpenSSL provient d'une erreur logique où la liste de révocation est chargée en mémoire mais jamais consultée activement lors du processus de poignée de main (handshake). Le serveur ne signale aucune erreur au démarrage, donnant aux opérateurs un faux sentiment de sécurité. Lorsqu'un client présente un certificat, le serveur valide sa signature contre l'autorité de confiance approuvée mais omet l'étape consistant à vérifier si le numéro de série spécifique de ce certificat figure sur la liste de révocation. Cela permet à tout certificat signé par une autorité de confiance d'accorder l'accès, indépendamment de son statut de révocation.

Le problème Mbed TLS implique une faute de frappe dans le code gérant les échanges de clés Diffie-Hellman sur corps finis. Au lieu de transmettre une valeur publique robuste de 2048 bits, le serveur envoie un seul octet. Les clients grand public comme les navigateurs modernes, Java et Go rejettent cette petite valeur et interrompent la connexion. Cependant, les clients embarqués ou personnalisés dépourvus de contrôles de taille minimale peuvent l'accepter, établissant une clé de session faible qu'un espion peut facilement calculer. Cette vulnérabilité n'affecte pas les sessions TLS 1.3 ou ECDHE.

Détails clés

• CVE-2026-115881 : Notée 9,1, affecte les compilations OpenSSL 3.4.5–6.1.0 avec TLS mutuel et listes de révocation configurées ; les certificats révoqués sont acceptés.
• CVE-2026-115884 : Notée 7,4, affecte les compilations LibreSSL 3.2.x et 3.3.2–3.3.6 ; permet des chaînes de certificats trop longues lorsque la vérification de l'émetteur est désactivée.
• Faille Mbed TLS : Notée 5,9, affecte les versions 4.0.2–6.1.0 ; envoie des valeurs Diffie-Hellman d'un octet, permettant le déchiffrement des sessions par des observateurs passifs.
• Disponibilité du correctif : GoAhead 6.1.1 résout tous les problèmes ; les propriétaires d'appareils doivent attendre que les fabricants expédient des mises à jour du micrologiciel contenant cette version.
• Correctif supplémentaire : La version 6.1.1 corrige également un contournement de connexion permettant l'accès avec n'importe quel mot de passe si le nom d'utilisateur est connu et stocké au format Blowfish.
• Détection : FoxIO propose des empreintes d'outils JA4Scan pour identifier les backends GoAhead, bien que cela identifie le type de compilation plutôt qu'une vulnérabilité confirmée.

Pourquoi c'est important

Pour les ingénieurs gérant l'infrastructure IoT, cet incident met en lumière l'opacité des chaînes d'approvisionnement logicielles embarquées. GoAhead fonctionne sur des routeurs, des imprimantes et des contrôleurs industriels de grands fournisseurs comme HP, Siemens et D-Link. Comme le backend TLS et les paramètres sont compilés dans le micrologiciel, les propriétaires d'appareils ne peuvent pas déterminer leur exposition sans inspection approfondie ou confirmation du fournisseur. Le délai entre la sortie du correctif aux fabricants en août et la divulgation publique en octobre souligne le cycle lent de correction typique des appareils embarqués, laissant les systèmes vulnérables pendant de longues périodes.

L'échec silencieux de la vérification de révocation est particulièrement dangereux pour les environnements reposant sur le TLS mutuel pour l'authentification des appareils. Les opérateurs qui configurent explicitement des listes de révocation pour gérer la sécurité du cycle de vie des appareils sont induits en erreur, croyant que leurs contrôles sont actifs. Cela mine la confiance dans les mécanismes d'authentification basés sur les certificats, qui constituent souvent la première ligne de défense pour les appareils sans interface utilisateur traditionnelle (headless). La présence d'un contournement de connexion dans la même version aggrave encore le risque, suggérant que plusieurs couches de défense peuvent être compromises simultanément.

Ce que vous pouvez faire

• Identifiez les appareils exécutant GoAhead dans votre environnement et contactez les fabricants pour confirmer s'ils ont expédié des micrologiciels basés sur la version 6.1.1.
• Si vous contrôlez le processus de compilation du micrologiciel, effectuez immédiatement la mise à niveau vers GoAhead 6.1.1 et reconstruisez vos images.
• Pour les compilations Mbed TLS, désactivez les suites DHE sur corps finis ou passez au backend OpenSSL comme mesure provisoire avant la mise à jour.
• Pour les compilations LibreSSL, activez la vérification de l'émetteur avec un bundle CA de confiance ou effectuez la mise à niveau vers LibreSSL 4.x si possible.
• Après la mise à niveau, terminez toutes les sessions actives, redémarrez le serveur et faites pivoter les mots de passe stockés au format Blowfish.
• Utilisez des outils comme JA4Scan pour relever les instances GoAhead et déterminer quel backend TLS elles utilisent, aidant ainsi à prioriser les efforts de remédiation.