Une faille discrète vient d’être corrigée dans l’une des bibliothèques TLS les plus utilisées du monde industriel et connecté, et pourtant presque personne n’en parle. CVE-2026-25832 touche Mbed TLS, le moteur cryptographique qui équipe des cartes électroniques, des passerelles domotiques et des équipements médicaux connectés bien au-delà des ordinateurs et des serveurs. Publiée le 14 septembre 2026 par le CVE Program et référencée par la National Vulnerability Database, la faille concerne la manière dont un client TLS 1.3 valide un message HelloRetryRequest pendant la négociation de la connexion. Son score CVSS de 3,7 sur 10 la classe en sévérité faible. Mais dans un monde où des millions d’objets connectés embarquent du code figé pendant des années, une faille “faible” peut rester active bien plus longtemps qu’un bug critique sur un serveur cloud patché en quelques heures. C’est tout l’enjeu de cette actualité du 29 septembre 2026 : comprendre pourquoi une erreur de validation dans le protocole TLS 1.3, jugée mineure sur le papier, mérite l’attention des équipes sécurité, des fabricants d’appareils IoT et des industriels qui s’appuient sur Mbed TLS pour sécuriser leurs communications.
CVE-2026-25832 : ce que révèle la fiche technique
La description officielle de CVE-2026-25832 tient en une phrase : dans Mbed TLS, les versions 3.6.x antérieures à 3.6.7 et 4.1.x antérieures à 4.1.2 acceptent, côté client, un message HelloRetryRequest qui sélectionne un groupe cryptographique non annoncé au préalable. Le CVE Program a publié l’avis le 14 septembre 2026, avec une dernière mise à jour enregistrée le 22 septembre 2026 selon les données de la NVD. Le vecteur CVSS 3.1 retenu est AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N, ce qui donne un score de base de 3,7, un score d’exploitabilité de 2,2 et un score d’impact de 1,4. Traduit en clair : l’attaque se joue sur le réseau, sans droits particuliers ni interaction de la victime, mais elle exige des conditions de négociation TLS inhabituelles pour aboutir. L’impact documenté se limite à une atteinte faible à l’intégrité, sans conséquence sur la confidentialité ni sur la disponibilité du service.
Red Hat a publié sa propre fiche via son portail de sécurité, précisant que la faille pourrait permettre à un attaquant distant de provoquer un impact faible sur l’intégrité de la session, tout en indiquant explicitement qu’aucun produit actuellement supporté par Red Hat n’est concerné. Aucune preuve de concept publique ni exploitation active n’a été signalée à ce jour, et le CVE n’apparaît pas dans le catalogue Known Exploited Vulnerabilities de la CISA. Les versions corrigées, 3.6.7 pour la branche 3.6 et 4.1.2 pour la branche 4.1, sont disponibles depuis la publication de l’avis de sécurité du projet Mbed TLS.
HelloRetryRequest et supported_groups : la mécanique de TLS 1.3 mise en cause
Pour comprendre la portée de CVE-2026-25832, il faut revenir à la mécanique de négociation de TLS 1.3, normalisée par l’IETF dans la RFC 8446. Quand un client initie une connexion, il envoie un ClientHello contenant deux informations distinctes : l’extension supported_groups, qui liste tous les groupes de courbes elliptiques ou de champs finis qu’il est prêt à utiliser, et l’extension key_share, qui contient les clés éphémères réellement générées pour un sous-ensemble de ces groupes. Générer une clé pour chaque groupe supporté coûterait trop de calcul, donc le client n’en propose généralement qu’un ou deux au départ.
Si le serveur préfère un groupe pour lequel le client n’a pas fourni de clé, il répond par un HelloRetryRequest (HRR), un mécanisme introduit spécifiquement par TLS 1.3 pour éviter un aller-retour de négociation supplémentaire. Le HRR indique au client le groupe sélectionné, et le client doit alors renvoyer un second ClientHello avec la clé correspondante. La règle de sécurité implicite du protocole est stricte : le groupe choisi dans le HRR doit obligatoirement figurer dans la liste supported_groups envoyée initialement par le client. Un serveur, malveillant ou compromis, ne devrait jamais pouvoir imposer un groupe que le client n’a jamais annoncé vouloir utiliser.
C’est précisément cette vérification qui faisait défaut dans les versions vulnérables de Mbed TLS. Le client acceptait un groupe sélectionné par le serveur dans le HRR même lorsque ce groupe n’apparaissait pas dans son propre supported_groups d’origine. L’avis de sécurité du projet Mbed TLS confirme que le correctif consiste précisément à réintroduire cette vérification manquante entre le groupe reçu dans le HRR et la liste annoncée par le client.
Pourquoi Mbed TLS a laissé passer un groupe non annoncé
Il est tentant, à la lecture du mot “courbe elliptique”, de penser que cette faille remet en cause la solidité mathématique de la cryptographie à courbes elliptiques. Ce n’est pas le cas. CVE-2026-25832 est un défaut de validation d’état du protocole, pas une rupture algorithmique. Aucune donnée publique ne suggère qu’un attaquant puisse récupérer une clé de session, déchiffrer du trafic ou casser une courbe comme secp256r1, secp384r1 ou X25519. Le problème se situe une étape avant le calcul cryptographique lui-même, dans la machine à états qui décide quels paramètres sont légitimes.
Concrètement, un serveur pouvait pousser un client Mbed TLS vulnérable vers un groupe cryptographique que ce client n’avait jamais eu l’intention d’utiliser. Les conséquences documentées restent limitées à un comportement de négociation incohérent : possible échec de handshake, usage d’un groupe hors politique de sécurité de l’application, ou incohérence entre la configuration attendue et l’état réel de la session. Il n’existe, à ce stade, aucune démonstration publique d’un scénario allant jusqu’au déchiffrement de trafic. C’est cette distinction entre bug d’implémentation et faille cryptographique fondamentale qui explique pourquoi le score CVSS reste bas malgré la nature sensible du composant touché.
CVSS 3,7 : faible sur le papier, embêtant en pratique
Un score de 3,7 place CVE-2026-25832 tout en bas de l’échelle des sévérités CVSS. Sur un serveur web classique, ce type de score se traduit souvent par un correctif appliqué au prochain cycle de maintenance, sans urgence particulière. Le problème, c’est que Mbed TLS n’équipe pas des serveurs web. Le projet cible en priorité les environnements à ressources contraintes : microcontrôleurs, passerelles IoT, équipements industriels, modules de démarrage sécurisé et produits embarqués dans l’automobile ou la santé connectée.
Sur ce type de matériel, un correctif logiciel n’est jamais une simple mise à jour de paquet. Il faut recompiler le firmware, requalifier l’ensemble de la chaîne cryptographique, parfois repasser par une certification réglementaire, avant de distribuer la mise à jour via un mécanisme de gestion de parc souvent limité. Un score CVSS bas ne garantit donc pas un correctif rapide sur le terrain, il retarde simplement la prise de conscience de l’urgence réelle. C’est un point que les équipes sécurité qui gèrent des parcs d’objets connectés devraient garder en tête avant de classer CVE-2026-25832 comme négligeable.
Mbed TLS, TrustedFirmware, Arm : une bibliothèque discrète mais omniprésente
Mbed TLS n’a jamais eu la notoriété d’OpenSSL, mais elle occupe une position stratégique dans l’écosystème embarqué. Le projet, initialement connu sous le nom de PolarSSL, a été racheté par Arm en 2015 avant d’être confié à la gouvernance ouverte du projet TrustedFirmware, porté par la fondation Linaro. Les enregistrements officiels du CVE désignent d’ailleurs TrustedFirmware comme éditeur du produit Mbed TLS, signe que la bibliothèque a bien changé de statut au fil des années, passant d’un projet commercial à un composant open source gouverné collectivement.
Le positionnement de Mbed TLS reste sans équivalent direct : une implémentation TLS compacte, pensée pour tourner sur des microcontrôleurs disposant de quelques dizaines de kilooctets de mémoire, là où OpenSSL ou BoringSSL visent plutôt les serveurs et les systèmes d’exploitation complets. Aucune étude indépendante et vérifiable ne permet à ce jour de chiffrer précisément le nombre d’appareils déployés dans le monde utilisant Mbed TLS, la bibliothèque étant souvent intégrée de façon statique dans des firmwares propriétaires et difficile à recenser depuis l’extérieur. Cette opacité du marché embarqué est elle-même une partie du problème : impossible de mesurer l’exposition réelle à une faille comme CVE-2026-25832 sans un audit direct du parc installé.
Chronologie complète de la divulgation
Le tableau ci-dessous résume les dates clés confirmées par la NVD et par l’avis de sécurité du projet Mbed TLS, disponible sur son dépôt GitHub officiel.
| Étape | Date ou version | Source |
|---|---|---|
| Branche 3.6.x vulnérable | 3.5.0 jusqu’à 3.6.6 inclus | NVD / CVE Program |
| Branche 4.x vulnérable | 4.0.0 jusqu’à 4.1.1 inclus | NVD / CVE Program |
| Publication du CVE | 14 septembre 2026 | NVD (services.nvd.nist.gov) |
| Version corrigée branche 3.6 | 3.6.7 | Avis de sécurité Mbed TLS / GitHub |
| Version corrigée branche 4.x | 4.1.2 | Avis de sécurité Mbed TLS / GitHub |
| Dernière mise à jour de la fiche | 22 septembre 2026 | NVD |
| Preuve de concept publique | Aucune signalée | NVD / Red Hat |
| Présence au catalogue CISA KEV | Absente | CISA |
Mbed TLS face à OpenSSL, BoringSSL, wolfSSL et rustls
Aucune source vérifiable ne permet aujourd’hui d’affirmer qu’OpenSSL, BoringSSL, wolfSSL, GnuTLS ou rustls partagent le même défaut de validation du HelloRetryRequest que Mbed TLS, ni qu’ils en sont exempts par construction. Établir une telle comparaison exigerait un audit dédié du traitement du HRR dans chacune de ces bases de code, ce qui dépasse le cadre d’un avis de sécurité isolé. Ce que l’on peut en revanche comparer objectivement, ce sont les positionnements publics de chaque projet, qui expliquent pourquoi Mbed TLS reste une cible probable de ce type de faille embarquée.
| Bibliothèque | Mainteneur / gouvernance | Environnement cible privilégié | Licence |
|---|---|---|---|
| Mbed TLS | TrustedFirmware (Linaro), héritage Arm | Microcontrôleurs, IoT, firmware embarqué | Apache 2.0 |
| OpenSSL | OpenSSL Software Foundation | Serveurs, systèmes d’exploitation généralistes | Apache 2.0 |
| BoringSSL | Produits et infrastructure Google | Licence mixte OpenSSL/ISC | |
| wolfSSL | wolfSSL Inc. | Embarqué, IoT, automobile, dispositifs médicaux | GPLv2 / commerciale |
| rustls | Communauté Rust (Prossimo/ISRG) | Applications visant la sécurité mémoire | Apache 2.0 / MIT |
Ce tableau illustre une réalité simple : Mbed TLS et wolfSSL se disputent le même terrain, celui des appareils à ressources limitées, quand OpenSSL et BoringSSL restent concentrés sur des environnements serveurs où le cycle de correctif est bien plus rapide. Le précédent examen par shattered.io des failles TLS touchant curl, OpenSSL et wolfSSL avait déjà souligné cet écart de rythme de correction entre les deux mondes.
Quels secteurs sont réellement exposés
Sans inventaire précis du parc installé, il reste possible de raisonner par catégorie d’usage. Mbed TLS est historiquement positionné pour les équipements médicaux connectés (moniteurs, pompes à perfusion, passerelles hospitalières), l’automobile (télématique, modules de diagnostic, calculateurs embarqués), l’IoT industriel (capteurs, automates, passerelles de supervision) et l’électronique grand public connectée (caméras, hubs domotiques, objets connectés). La faille ne concerne que les produits agissant comme client TLS 1.3 sortant face à un serveur potentiellement malveillant, ce qui exclut d’office les appareils qui se contentent de recevoir des connexions entrantes sans jamais initier de session TLS 1.3 sortante.
Les secteurs les plus exposés sont donc ceux où les objets appellent régulièrement des serveurs distants pour récupérer des mises à jour, transmettre de la télémétrie ou synchroniser des données patient, tout en tournant sur des versions de Mbed TLS figées depuis plusieurs cycles de production. C’est précisément dans ces secteurs, santé et automobile en tête, que le décalage entre un score CVSS faible et un risque opérationnel réel est le plus marqué.
2025-2026 : une série de failles d’implémentation TLS et ECC
CVE-2026-25832 ne surgit pas dans un désert. Ces derniers mois, plusieurs failles ont rappelé que les implémentations de TLS restent une source récurrente de vulnérabilités, indépendamment de la solidité des algorithmes sous-jacents. Shattered.io a par exemple documenté la vague de six CVE ayant touché TLS 1.3 en six semaines plus tôt cette année, ainsi que les quatre failles TLS corrigées dans curl 8.22.0, qui touchaient à la fois OpenSSL et wolfSSL. Plus récemment, la réémergence de la vulnérabilité historique de Bleichenbacher sous la référence CVE-2026-69247 dans la bibliothèque Python cryptography a montré que même des classes de bugs vieilles de près de trente ans continuent de resurgir dans de nouvelles implémentations.
Sur le plan normatif, l’IETF a par ailleurs entrepris une réécriture de la spécification TLS 1.3 elle-même via la RFC 9846, qui rend obsolètes plusieurs RFC antérieures dans le but de clarifier des zones d’ombre du protocole. Ce contexte normatif renforce l’idée que la mécanique de négociation de TLS 1.3, aussi robuste soit-elle sur le papier, continue de produire des angles morts d’implémentation d’une bibliothèque à l’autre.
Ce que disent les chercheurs de la sécurité TLS dans l’IoT
Le déploiement de TLS sur des appareils contraints en ressources pose des défis connus des chercheurs en sécurité depuis plusieurs années, bien avant CVE-2026-25832. John Graham-Cumming, directeur technique de Cloudflare, résumait déjà la difficulté en des termes qui restent d’actualité : “There are three problems developers run into when they want to implement TLS in IoT. The first is that while IoT traffic needs to be quick and lightweight, TLS adds an additional two round trips to the start of every session. The second is that certificates can be large files, and device memory is limited in IoT. And the third is that some of the protocols that are being developed for IoT are plaintext by default”, expliquait-il sur le blog technique de Cloudflare.
Graham-Cumming allait plus loin sur les limites pratiques de TLS 1.3 dans ce contexte, ironisant : “TLS 1.3 is going to save us all”, une formule qu’il utilisait précisément pour souligner que le protocole seul ne résout pas les contraintes matérielles et organisationnelles du monde IoT. Une étude de terrain sur la validation des certificats dans les objets connectés grand public, menée par le chercheur Stefan Saidi et publiée par l’institut IMDEA Networks, avait de son côté documenté un problème voisin sur le plan de la rigueur d’implémentation : “11 devices are vulnerable to TLS interception attacks because they do not properly validate server certificates”, écrivait-il dans son rapport de recherche sur l’usage de TLS dans l’IoT grand public. Ces constats, antérieurs à CVE-2026-25832, dessinent une tendance de fond : la validation rigoureuse des paramètres de négociation TLS reste le maillon faible des implémentations embarquées, bien plus que les algorithmes cryptographiques eux-mêmes.
Impact marché : le vrai coût du patching embarqué
Le coût réel de CVE-2026-25832 ne se mesure pas à son score CVSS mais au cycle de vie des produits qui embarquent Mbed TLS. Pour un fabricant, corriger une bibliothèque cryptographique embarquée implique de récupérer le correctif en amont, de recompiler le firmware complet, de faire passer une nouvelle campagne de tests de régression et, dans les secteurs réglementés comme la santé ou l’automobile, d’obtenir une revalidation avant toute distribution. Ce cycle peut s’étaler sur plusieurs mois, alors qu’un correctif équivalent sur un serveur Linux classique se déploie en quelques heures via un gestionnaire de paquets.
Le contexte réglementaire européen ajoute une pression supplémentaire sur ce calendrier. Le Cyber Resilience Act impose désormais aux fabricants de produits connectés vendus dans l’Union européenne de signaler les vulnérabilités activement exploitées dans des délais resserrés et de maintenir un processus de correction tout au long du cycle de vie du produit. Une faille comme CVE-2026-25832, même non exploitée à ce jour, entre dans le périmètre de cette obligation de suivi continu, ce qui pousse mécaniquement les fabricants à documenter et à planifier une mise à jour de leur chaîne Mbed TLS plutôt qu’à ignorer un score CVSS jugé faible.
Vers la cryptographie post-quantique : le chantier de fond
CVE-2026-25832 rappelle aussi, en creux, l’ampleur du chantier qui attend les bibliothèques TLS embarquées à mesure que la transition vers la cryptographie post-quantique s’accélère. Les mécanismes d’échange de clés hybrides combinant courbes elliptiques classiques et algorithmes résistants au calcul quantique, comme ML-KEM, ajoutent de nouveaux groupes et de nouvelles extensions à négocier dans le handshake TLS 1.3, exactement le terrain où se situait le défaut de validation corrigé cette semaine. Chaque nouveau groupe cryptographique introduit dans supported_groups est un point de validation supplémentaire susceptible d’être mal implémenté.
Pour les bibliothèques dédiées aux environnements contraints comme Mbed TLS, cette montée en complexité du handshake TLS 1.3 post-quantique va de pair avec des ressources de calcul et de mémoire qui restent, elles, limitées par le matériel. L’équation devient plus délicate à mesure que le nombre de groupes cryptographiques pris en charge augmente, ce qui renforce l’intérêt de disposer d’une validation stricte et systématique de chaque paramètre négocié, précisément ce qui faisait défaut dans les versions de Mbed TLS concernées par CVE-2026-25832.
Nos prédictions pour les prochains mois
- L’adoption des correctifs 3.6.7 et 4.1.2 restera lente sur les parcs industriels et médicaux, la recompilation et la requalification des firmwares prenant généralement plusieurs mois dans ces secteurs.
- D’autres bibliothèques TLS ciblant l’embarqué devraient faire l’objet d’audits similaires sur leur traitement du HelloRetryRequest, par effet d’entraînement après la publication de CVE-2026-25832.
- La pression réglementaire du Cyber Resilience Act va pousser davantage de fabricants IoT à publier des nomenclatures logicielles précisant leur version exacte de Mbed TLS ou d’une bibliothèque équivalente.
- L’arrivée progressive des groupes post-quantiques dans les handshakes TLS 1.3 embarqués va complexifier la surface de validation des extensions de négociation, augmentant mécaniquement le risque de bugs similaires.
- Les projets misant sur des implémentations mémoire-sûres comme rustls devraient gagner en visibilité dans les appels d’offres embarqués sensibles, sans pour autant remplacer à court terme des bases installées aussi larges que Mbed TLS ou wolfSSL.
Comment vérifier et corriger son exposition à CVE-2026-25832
La première étape consiste à identifier précisément la version de Mbed TLS embarquée dans chaque produit ou chaque firmware, en particulier lorsque la bibliothèque est liée statiquement, ce qui rend une simple mise à jour de paquet système insuffisante. Les équipes doivent ensuite vérifier si le composant agit en tant que client TLS 1.3 sortant, condition nécessaire à l’exploitation de la faille. Le code suivant illustre, à titre d’exemple, comment un projet basé sur Mbed TLS peut vérifier sa version compilée avant de planifier une mise à jour vers 3.6.7 ou 4.1.2.
#include "mbedtls/version.h"
#include <stdio.h>
int main(void) {
char version[18];
mbedtls_version_get_string_full(version);
printf("Version Mbed TLS détectée : %s\n", version);
/* Comparer avec 3.6.7 (branche 3.6) ou 4.1.2 (branche 4.x) */
return 0;
}Une fois la version confirmée comme vulnérable, la mise à niveau vers 3.6.7 ou 4.1.2 doit suivre le cycle de test habituel du produit avant tout déploiement en production, en particulier sur les équipements médicaux ou automobiles soumis à certification. Pour resituer cette faille dans l’ensemble des enjeux de cryptographie couverts par la rédaction, elle s’ajoute à une liste déjà longue de bugs d’implémentation touchant des protocoles pourtant considérés comme matures.
Foire aux questions
Qu’est-ce que CVE-2026-25832 exactement ?
C’est une faille de validation dans le client TLS 1.3 de Mbed TLS, qui acceptait un groupe cryptographique sélectionné par le serveur dans un message HelloRetryRequest sans vérifier que ce groupe avait bien été annoncé au préalable par le client.
Mon appareil IoT est-il vulnérable ?
Il l’est potentiellement s’il embarque Mbed TLS en version 3.5.0 à 3.6.6, ou 4.0.0 à 4.1.1, et s’il initie des connexions TLS 1.3 sortantes vers des serveurs distants. Les appareils qui ne font qu’accepter des connexions entrantes ne sont pas concernés par ce scénario précis.
Pourquoi le score CVSS est-il si bas alors que la faille touche TLS 1.3 ?
Le score de 3,7 reflète une complexité d’attaque élevée et un impact limité à l’intégrité de la session, sans conséquence sur la confidentialité des données. Ce n’est pas une rupture de la cryptographie à courbes elliptiques, mais un défaut de validation d’état du protocole.
Faut-il mettre à jour immédiatement vers Mbed TLS 3.6.7 ou 4.1.2 ?
Oui, dès que le cycle de test du produit le permet, même si le score CVSS est faible, car le Cyber Resilience Act impose désormais un suivi continu des vulnérabilités connues sur les produits connectés vendus dans l’Union européenne.
Cette faille casse-t-elle la cryptographie à courbe elliptique ?
Non. Aucune donnée publique ne montre de rupture algorithmique de courbes comme secp256r1 ou X25519. Le problème se situe dans la logique de négociation TLS, avant tout calcul cryptographique.
Existe-t-il un exploit public pour CVE-2026-25832 ?
Non, ni la NVD ni Red Hat ne signalent de preuve de concept publique ou d’exploitation active à ce jour, et la faille n’apparaît pas dans le catalogue Known Exploited Vulnerabilities de la CISA.
Quelle est la différence entre Mbed TLS et OpenSSL ?
Mbed TLS cible les environnements à ressources limitées comme les microcontrôleurs et l’IoT, tandis qu’OpenSSL équipe majoritairement des serveurs et des systèmes d’exploitation complets disposant de bien plus de mémoire et de puissance de calcul.
Cette faille est-elle liée à la migration post-quantique ?
Pas directement, mais elle illustre un risque qui va s’amplifier : chaque nouveau groupe cryptographique post-quantique ajouté au handshake TLS 1.3 est un point de validation supplémentaire, dans exactement la zone du protocole où se situait ce bug.
