Un défaut dans la vérification cryptographique des certificats peut amener un système vulnérable à faire confiance à un faux serveur. Le correctif a déjà été publié par wolfSSL et doit désormais être déployé sur les produits concernés.
wolfSSL vient de patcher une faille critique dans sa bibliothèque TLS/SSL, utilisée pour sécuriser les connexions chiffrées d’une foule de routeurs, d’objets connectés, de systèmes industriels ou de plateformes comme FreeRTOS et OpenWRT. On la retrouve aussi dans des usages plus visibles, comme Lightway, le protocole VPN d’ExpressVPN. Un périmètre loin d’être marginal, alors que wolfSSL revendique plus de 5 milliards d’applications et d’appareils sécurisés par ses technologies.
Une vérification incomplète des signatures numériques
Référencée CVE-2026-5194 (CVSS 9.3), la vulnérabilité corrigée relève d’une faille cryptographique qui touche la vérification de certaines signatures numériques utilisées par les certificats. Elle concerne plusieurs algorithmes, dont ECDSA/ECC, DSA, ML-DSA, Ed25519 et Ed448, et se manifeste au moment où un appareil ou un logiciel doit décider s’il peut faire confiance à un serveur ou à un service.
Le problème tient à un contrôle incomplet de l’algorithme de hachage et de la taille du digest, soit l’empreinte numérique calculée à partir des données signées et utilisée comme base de la vérification. Dans certains cas, wolfSSL pouvait ainsi accepter un digest plus petit que celui normalement requis.
Un certificat pouvait donc être validé sur une base cryptographique plus faible qu’attendu. Un attaquant pouvait alors tenter de présenter un certificat forgé qu’un système vulnérable risquait d’accepter comme légitime. Si cette tentative aboutissait, un serveur ou un service malveillant pouvait se faire passer pour une entité de confiance et, selon le contexte, intercepter des échanges ou accéder à des informations qui n’auraient pas dû lui être accessibles.
Un correctif disponible, mais un inventaire à faire sans tarder
wolfSSL a corrigé CVE-2026-5194 dans la version 5.9.1, publiée le 8 avril 2026. La mise à jour concerne surtout les appareils et logiciels qui intègrent cette bibliothèque pour gérer les connexions TLS, en particulier dans les équipements embarqués, les objets connectés, les routeurs, certains systèmes industriels ou des environnements comme OpenWRT et FreeRTOS.
Pour les équipes techniques, le point de départ consiste donc à identifier les produits dans lesquels wolfSSL est présent, puis à vérifier quelle version est embarquée. Une tâche nécessaire, mais pas forcément suffisante pour agir tout de suite. Sur de nombreux équipements déjà en service, wolfSSL est en effet intégré au firmware ou à une pile logicielle fournie par un tiers, si bien que le déploiement du correctif dépendra ensuite du constructeur, de l’éditeur ou du fournisseur concerné.
Lors d’une connexion TLS, le client vérifie que le certificat présenté par le serveur a bien été signé par une autorité de certification de confiance et qu’il correspond au nom du service contacté. Cette étape repose sur des signatures numériques et une chaîne de certificats (du serveur jusqu’à une racine de confiance). Si la vérification est incomplète ou contournable, un attaquant peut faire accepter un certificat falsifié et se faire passer pour le serveur attendu. Le risque typique est une attaque de type "man-in-the-middle", où l’attaquant intercepte, modifie ou redirige le trafic chiffré. Sur des objets connectés ou des routeurs, cela peut aussi ouvrir la porte à des mises à jour frauduleuses ou à l’accès à des API internes.
Qu’est-ce qu’un digest (empreinte) et pourquoi sa taille compte dans la validation d’une signature numérique ?Un digest est l’empreinte produite par une fonction de hachage appliquée aux données à signer (ou à vérifier), et il sert d’entrée à l’algorithme de signature. La taille du digest attendue dépend de l’algorithme et des paramètres de sécurité : accepter une empreinte plus courte que prévu peut réduire la robustesse de la vérification. Concrètement, cela peut rendre certaines collisions ou manipulations plus plausibles, car la vérification porte alors sur moins d’information cryptographique. Une bibliothèque TLS doit donc contrôler strictement l’algorithme de hachage utilisé et la longueur de l’empreinte fournie. Un contrôle “trop permissif” peut transformer une validation de signature en validation affaiblie, ce qui n’est pas équivalent en termes de sécurité.
Pourquoi le correctif wolfSSL doit-il être déployé par les fabricants, même s’une nouvelle version existe déjà ?Dans beaucoup de produits embarqués (routeurs, IoT, systèmes industriels), wolfSSL est intégré au firmware ou à une pile logicielle fournie par un constructeur ou un sous-traitant. Mettre à jour la bibliothèque côté projet upstream ne met pas automatiquement à jour les appareils déjà vendus : il faut une nouvelle image logicielle, validée et distribuée par le fournisseur. De plus, certains équipements utilisent des versions “forkées” ou des configurations spécifiques qui demandent un travail d’intégration et de tests de non-régression. La première étape est donc un inventaire précis (présence de wolfSSL, version, options de compilation, composants qui l’emploient), puis la planification du déploiement via mises à jour OTA, packages ou correctifs firmware. Tant que cette chaîne de mise à jour n’est pas réalisée, les systèmes restent potentiellement exposés malgré la disponibilité du patch.
