Une faille corrigée depuis fin juin 2026 mais détaillée publiquement début septembre remet en cause la solidité de l’une des bibliothèques les plus déployées dans l’embarqué et l’IoT. wolfSSL, éditeur américain dont le code tourne dans des millions d’appareils européens, a publié un correctif pour CVE-2026-10097, une faille qui permet de reconstituer une clé privée ML-KEM-1024 complète à partir d’environ 350 requêtes forgées. L’algorithme visé n’a rien d’un vestige : ML-KEM est le mécanisme d’échange de clés post-quantique que l’Union européenne, les États-Unis et la France poussent activement depuis deux ans pour remplacer RSA et les courbes elliptiques. Le bug ne touche pas la théorie mathématique de ML-KEM, validée par le NIST sous la référence FIPS 203, mais son implémentation optimisée pour les processeurs x64 dotés du jeu d’instructions AVX2. Une seconde faille, CVE-2026-11310, touche la même bibliothèque au niveau de la validation des chaînes de certificats X.509. Les deux bogues sont corrigés dans wolfSSL 5.9.2, mais leur exposition publique début septembre 2026 tombe deux jours après que le G7, sous présidence française, a exhorté gouvernements et industriels à accélérer leur bascule vers la cryptographie post-quantique.
Une faille au cœur de la cryptographie post-quantique
wolfSSL n’est pas un nom grand public, mais c’est un choix technique courant chez les fabricants de routeurs, d’automates industriels, de modules automobiles et d’objets connectés qui ont besoin d’une bibliothèque TLS légère, capable de tourner sur quelques dizaines de kilo-octets de mémoire. La société a été l’une des premières à intégrer ML-KEM dès la version 5.7.4, livrée en décembre 2024, peu après la standardisation officielle de l’algorithme par le NIST sous FIPS 203. Cette avance technique, longtemps présentée comme un avantage commercial face à des concurrents plus lents à migrer, se retourne aujourd’hui contre l’éditeur : c’est justement le code d’accélération ML-KEM-1024, optimisé pour le jeu d’instructions AVX2 des processeurs x64, qui contient la faille.
ML-KEM (Module-Lattice Key Encapsulation Mechanism) sert à établir une clé de session partagée entre deux machines, un rôle que RSA et les courbes elliptiques occupaient depuis trente ans dans TLS. La bascule vers cet algorithme accélère nettement : Cloudflare rapportait déjà plus de 60 % des requêtes HTTPS sur son réseau protégées par un échange post-quantique hybride dès février 2026, un chiffre passé à plus des deux tiers du trafic humain entre avril et juin 2026, selon les données publiées par l’entreprise et reprises par Encryption Consulting. Notre comparatif ML-KEM face à RSA et ECDH détaillait déjà cette progression. C’est précisément parce que ML-KEM sort du stade expérimental pour devenir un composant de production que la fiabilité de ses implémentations devient un sujet critique, et non plus un détail académique.
CVE-2026-10097 : comment un octet manquant expose une clé privée entière
Le cœur du problème tient à une fonction de comparaison de quelques lignes de code, mlkem_cmp_avx2, chargée de vérifier qu’un texte chiffré ML-KEM-1024 correspond bien à ce qu’attend le protocole avant de livrer le secret partagé. D’après la fiche technique publiée par le National Vulnerability Database via OpenCVE, cette fonction ne compare que 1 536 des 1 568 octets qui composent un texte chiffré ML-KEM-1024. Les 32 derniers octets, ceux qui vont de la position 1536 à 1567, ne sont tout simplement jamais vérifiés dans la version accélérée AVX2 du code.
Le rôle de la transformation Fujisaki-Okamoto
ML-KEM repose sur une construction appelée transformation Fujisaki-Okamoto, un mécanisme de sécurité qui protège l’algorithme contre les attaques par texte chiffré choisi. Concrètement, lors du déchiffrement, le système reconstruit le texte chiffré attendu et le compare octet par octet à celui reçu. Si la comparaison échoue, ML-KEM ne renvoie pas d’erreur explicite : par construction, il renvoie un secret de rejet indiscernable d’un vrai secret, une technique dite de rejet implicite censée empêcher un attaquant de savoir si sa tentative a réussi. C’est précisément cette protection que la comparaison tronquée annule. Un texte chiffré modifié uniquement sur ses 32 derniers octets passe la vérification comme s’il était valide, et le déchiffreur renvoie alors le véritable secret partagé au lieu du secret de rejet.
Le résultat transforme le point de déchiffrement en oracle : un attaquant qui peut observer, même indirectement, si une session TLS aboutit avec succès ou échoue apprend une information sur la clé privée à chaque requête forgée qu’il envoie. La documentation officielle de l’éditeur, publiée sur la page de sécurité de wolfSSL, précise que ce défaut est un bogue logique déterministe et non une attaque par mesure de temps d’exécution : il ne repose sur aucune fuite de type side-channel, ce qui le rend plus simple à exploiter de façon fiable qu’une attaque temporelle classique.
350 requêtes pour une clé complète
Une preuve de concept citée dans plusieurs bases de vulnérabilités, dont CVE Brief, indique qu’environ 350 textes chiffrés forgés suffisent pour reconstituer une clé privée ML-KEM-1024 complète, avec un taux de réussite proche de 98 %. Comparé aux attaques classiques contre RSA ou les courbes elliptiques, qui demandent souvent des milliers de mesures et un accès précis au temps d’exécution, 350 requêtes représentent un volume d’attaque modeste, largement à la portée d’un service exposé sur Internet qui traite des connexions TLS en continu. La note CVSS attribuée varie selon les bases : 7,5 sur les évaluateurs Strix et PatchCVE, jusqu’à 8,3 pour DevGuard et CVE Brief. Dans les deux cas, la faille est classée en sévérité élevée.
Aucune source consultée ne rapporte d’exploitation confirmée sur des systèmes en production à ce jour. Un flux de veille cité par plusieurs agrégateurs de CVE indique littéralement qu’aucun exploit public n’existe et qu’un correctif doit être appliqué à titre préventif. Cela ne rassure qu’à moitié : la faille est connue, documentée avec suffisamment de détails techniques pour être reproduite, et touche des systèmes dont le cycle de mise à jour, dans l’embarqué, se compte parfois en années plutôt qu’en semaines.
CVE-2026-11310 : la confiance PKI contournée
La seconde faille touche un tout autre composant : la fonction wolfSSL_X509_verify_cert(), qui imite le comportement de la fonction équivalente d’OpenSSL pour vérifier une chaîne de certificats X.509. D’après le suivi de sécurité de Debian, le problème ne concerne que les compilations activant la couche de compatibilité OpenSSL, via l’option --enable-opensslextra. Dans ce mode, l’application fournit des certificats intermédiaires non fiables à la fonction de vérification, qui doit normalement construire une chaîne de confiance jusqu’à une autorité racine reconnue. Le bogue vient du fait que ces intermédiaires non fiables ne sont jamais retirés avant que le moteur de vérification n’effectue son contrôle final, ce qui permet à un certificat intermédiaire fourni par l’attaquant d’être traité comme une ancre de confiance légitime.
Concrètement, un attaquant capable de présenter une chaîne de certificats manipulée peut faire accepter un certificat qui n’a jamais été validé par une autorité de certification reconnue. Dans un contexte industriel, cela ouvre la porte à des scénarios d’interception ou à la validation frauduleuse de serveurs de mise à jour firmware, un vecteur particulièrement sensible pour les équipementiers qui signent leurs micrologiciels. La faille affecte les versions 5.8.4, 5.9.0 et 5.9.1 de wolfSSL, et le correctif est disponible depuis la version 5.9.2. Signe que la propagation reste lente, les paquets Debian 11, 12 et 13 étaient encore marqués « sans correctif » début septembre 2026, plusieurs mois après la publication de la faille par l’éditeur.
Chronologie : de la découverte au correctif
Les deux failles suivent un calendrier proche mais pas identique. wolfSSL a publié le correctif des deux problèmes dans la version 5.9.2, sortie fin juin 2026. Les identifiants CVE-2026-10097 et CVE-2026-11310 ont ensuite été attribués et documentés le 25 juin 2026 dans les bases publiques. La couverture médiatique spécialisée est arrivée par vagues : un premier article technique sur les correctifs wolfSSL le 30 juin, une analyse plus détaillée début août, puis une remise à jour de la fiche NVD début septembre qui a relancé l’attention des équipes de sécurité. Ce délai de plusieurs mois entre le correctif upstream et sa prise en compte réelle par les distributions et les intégrateurs illustre un problème récurrent de la chaîne d’approvisionnement logicielle : corriger le code source ne suffit pas si les paquets binaires et les firmwares qui en dépendent ne sont jamais recompilés.
wolfSSL, pilier discret de l’IoT et de l’embarqué européen
La documentation commerciale de wolfSSL revendique un usage large dans l’automobile, l’aéronautique et le contrôle industriel, avec un support natif pour les systèmes temps réel comme FreeRTOS ou ThreadX, très répandus dans les calculateurs embarqués européens. La bibliothèque est également packagée dans les distributions Debian utilisées sur des passerelles industrielles et des équipements de périphérie, ce qui explique pourquoi le statut « sans correctif » des paquets Debian pèse particulièrement lourd. Les sources publiques ne permettent pas de citer des noms précis d’équipementiers européens utilisant wolfSSL pour ML-KEM, faute de communication détaillée de leur part, mais le positionnement de l’éditeur sur les environnements contraints en mémoire et conformes CNSA 2.0 en fait un choix naturel pour les cartes à puce, les compteurs intelligents et les modules de télématique automobile, des catégories de produits massivement présentes sur le marché européen.
Comparatif des deux failles wolfSSL
| Critère | CVE-2026-10097 | CVE-2026-11310 |
|---|---|---|
| Composant touché | Comparaison AVX2 des textes chiffrés ML-KEM-1024 (mlkem_cmp_avx2) | Vérification de chaîne X.509 en mode compatibilité OpenSSL (wolfSSL_X509_verify_cert()) |
| Score CVSS | 7,5 à 8,3 selon les bases | 7,5 (sévérité élevée) |
| Cause racine | Comparaison tronquée à 1 536 des 1 568 octets attendus | Certificats intermédiaires non fiables conservés avant le contrôle final |
| Versions affectées | 5.7.0 à 5.9.1 | 5.8.4, 5.9.0, 5.9.1 |
| Version corrigée | 5.9.2 | 5.9.2 |
| Exploitation confirmée | Aucune signalée | Aucune signalée |
| Date de publication | 25 juin 2026 | 25 juin 2026 |
ML-KEM face à la concurrence : OpenSSL, BoringSSL et liboqs restent indemnes
La question qui suit logiquement une telle découverte est simple : les autres bibliothèques qui implémentent ML-KEM ont-elles le même problème ? Les recherches disponibles ne font état d’aucune CVE spécifique à l’implémentation ML-KEM d’OpenSSL, de BoringSSL ou de liboqs en 2026. OpenSSL a intégré un support natif de ML-KEM, ML-DSA et SLH-DSA depuis sa branche 3.5, sortie en avril 2025, une intégration saluée à l’époque par le média technique allemand Heise comme la fin de la dépendance au fournisseur externe Open Quantum Safe. BoringSSL, la bibliothèque de Google utilisée par Chrome, propose le groupe hybride X25519MLKEM768 depuis un correctif intégré en 2024, aujourd’hui activé par défaut dans la majorité des installations de Chrome, Edge et Firefox. Le projet Open Quantum Safe (liboqs), plateforme de référence pour la recherche post-quantique, a lui aussi ajouté un support stable de ML-KEM avec sa version 0.14.0, publiée le 21 août 2025.
Cette absence de CVE ailleurs ne prouve évidemment pas que ces implémentations sont exemptes de bogues, seulement qu’aucune faille de cette nature n’a été rendue publique à ce jour. Elle situe néanmoins CVE-2026-10097 comme la première vulnérabilité documentée d’une implémentation ML-KEM chez un acteur majeur du marché TLS, un précédent que les équipes de sécurité surveilleront de près à mesure que d’autres bibliothèques accélèrent, elles aussi, leur code post-quantique pour le rendre compétitif face à RSA en matière de performance.
| Bibliothèque | Support ML-KEM depuis | CVE ML-KEM connue en 2026 | Contexte d’adoption |
|---|---|---|---|
| wolfSSL / wolfCrypt | Version 5.7.4, décembre 2024 | CVE-2026-10097 (AVX2, x64) | Embarqué, IoT, automobile, conformité CNSA 2.0 |
| OpenSSL | Branche 3.5, avril 2025 | Aucune signalée | Bibliothèque de référence pour serveurs auto-hébergés |
| BoringSSL | Groupe X25519MLKEM768, 2024 | Aucune signalée | Moteur par défaut de Chrome et de nombreux services Google |
| Open Quantum Safe (liboqs) | Version 0.14.0, août 2025 | Aucune signalée | Plateforme de recherche et de test post-quantique |
Une faille qui tombe au pire moment pour le G7
Le timing donne à cette histoire une résonance particulière. Le 3 septembre 2026, le groupe de travail cybersécurité du G7, présidé par l’ANSSI dans le cadre de la présidence française du G7, a publié un document conjoint intitulé « Preparing for the Post-Quantum Era: A Call to Action », signé par les agences de cybersécurité des sept pays membres et soutenu par la Commission européenne et l’ENISA en tant que participants invités, selon le communiqué publié sur cyber.gouv.fr. Le texte, relayé également par Infosecurity Magazine, presse gouvernements et entreprises de ne plus traiter la migration post-quantique comme un chantier lointain. Notre article sur l’appel à l’action du G7 revient en détail sur ce texte.
Deux jours après cette publication, la mise à jour de la fiche NVD sur CVE-2026-10097, datée du 6 septembre 2026, a ramené la faille wolfSSL sous les projecteurs. Le message envoyé aux entreprises est presque contradictoire en apparence : d’un côté, les autorités demandent d’accélérer l’adoption de ML-KEM, de l’autre, la première implémentation industrielle largement déployée de cet algorithme vient de montrer qu’un bogue d’implémentation peut annuler toute la sécurité théorique promise par l’algorithme. En France, l’ANSSI a par ailleurs annoncé qu’elle cesserait de certifier des produits de sécurité dépourvus de cryptographie post-quantique à partir de 2027, une échéance que nous détaillons dans notre dossier post-quantique de la rédaction. L’épisode wolfSSL illustre concrètement pourquoi ces certifications devront porter non seulement sur le choix de l’algorithme, mais sur la qualité de son implémentation.
Contexte historique : quand l’implémentation trahit l’algorithme
L’histoire de la cryptographie appliquée regorge d’épisodes où un algorithme mathématiquement solide s’est effondré à cause d’une implémentation bâclée. Heartbleed, découvert en 2014 dans OpenSSL, ne cassait ni AES ni RSA : il exploitait une erreur de lecture mémoire dans l’extension heartbeat pour extraire des clés privées et des données en clair depuis la mémoire d’un serveur, sur une bibliothèque utilisée par une part considérable des sites HTTPS de l’époque. La vulnérabilité ROCA, révélée en 2017, touchait une bibliothèque de génération de clés RSA développée par Infineon et embarquée dans des millions de cartes à puce et de jetons matériels, dont les cartes d’identité électroniques estoniennes, retirant à l’algorithme RSA lui-même toute sa robustesse théorique à cause d’un défaut dans la manière de générer les nombres premiers.
CVE-2026-10097 s’inscrit dans cette même lignée : ML-KEM, validé par des années d’analyse académique et un processus de standardisation NIST rigoureux, reste vulnérable si le code qui le met en œuvre coupe un coin pour gagner quelques cycles processeur. La différence, cette fois, tient à la nature encore jeune de l’écosystème post-quantique : contrairement à RSA, qui a bénéficié de décennies d’audits croisés, les implémentations ML-KEM commencent tout juste à être testées à grande échelle, et ce genre de défaut pourrait ne pas être isolé.
Impact marché : la facture pour les fournisseurs et intégrateurs
Pour les fabricants d’équipements qui ont intégré wolfSSL avec le support ML-KEM-1024 en environnement x64, la remédiation ne se limite pas à appliquer un correctif logiciel. Toute clé ML-KEM-1024 statique exposée à des textes chiffrés non fiables, par exemple sur un serveur qui accepte des connexions TLS 1.3 depuis Internet, doit théoriquement être régénérée après la mise à jour, puisqu’une clé compromise avant le correctif reste compromise après. Ce cycle d’audit, de mise à jour puis de rotation de clés représente un coût opérationnel qui touche en particulier les intégrateurs de matériel embarqué, où le simple fait de pousser une mise à jour firmware sur un parc déployé peut prendre des mois.
La faille CVE-2026-11310 ajoute une seconde ligne à cette facture : les équipes qui compilent wolfSSL avec la couche de compatibilité OpenSSL doivent vérifier leur configuration de vérification de certificats, un point souvent invisible dans les tests fonctionnels classiques puisqu’il ne casse rien en apparence, il affaiblit seulement une garantie de sécurité. Pour les distributeurs Linux comme Debian, dont les paquets wolfSSL restaient non corrigés début septembre, le décalage entre le correctif amont et sa disponibilité en aval illustre un coût indirect que la filière logicielle connaît bien mais peine toujours à résorber.
Comment se protéger : la check-list de remédiation
Pour les équipes techniques qui utilisent wolfSSL, la marche à suivre tient en quelques étapes concrètes, résumées ci-dessous.
1. Identifier les déploiements wolfSSL compilés entre les versions 5.7.0 et 5.9.1
2. Vérifier si ML-KEM-1024 est actif avec l'optimisation AVX2 sur cibles x64
3. Mettre à niveau vers wolfSSL 5.9.2 ou une version ultérieure
4. Régénérer toute clé ML-KEM-1024 statique exposée à des connexions entrantes
5. Vérifier si le build utilise --enable-opensslextra (couche OpenSSL)
6. Auditer la logique de vérification de certificats côté application
7. Suivre l'avancement du correctif dans les paquets de la distribution utilisée
8. Documenter la remédiation pour les audits de conformité NIS2 et ANSSICette liste ne dispense pas d’une analyse au cas par cas : un appareil qui n’accepte jamais de textes chiffrés provenant de sources non authentifiées réduit fortement la surface d’exploitation de CVE-2026-10097, tandis qu’un service exposé publiquement doit traiter la remédiation en priorité absolue.
Ce que cela signifie pour la trajectoire post-quantique française et européenne
La France a fait de la migration post-quantique un axe fort de sa politique de cybersécurité, avec une échéance de certification ANSSI fixée à 2027 pour les produits visant les usages régulés, données classifiées et systèmes d’information d’importance vitale. L’affaire wolfSSL ne remet pas en cause cette trajectoire, mais elle en révèle la difficulté d’exécution : recommander un algorithme ne suffit pas, il faut aussi que l’écosystème d’implémentations, souvent porté par des éditeurs de taille modeste comme wolfSSL, dispose des ressources d’audit nécessaires pour éviter ce type d’erreur. La comparaison avec le dossier GnuTLS et wolfSSL touchés par trois CVE en sept semaines, publié en août 2026 sur des failles distinctes de validation de certificats, montre que ce n’est pas un cas isolé pour cette bibliothèque cette année.
Le contexte réglementaire européen ajoute une pression supplémentaire. NIS2 impose déjà aux opérateurs de services essentiels une obligation de gestion des vulnérabilités, et les autorités françaises, qui n’avaient pas achevé la transposition complète de la directive fin août 2026, devront composer avec des dossiers comme celui-ci pour calibrer leurs exigences. Le débat entre HQC et ML-KEM, deux mécanismes retenus par le NIST comme solutions post-quantiques, que nous abordions dans notre comparatif HQC contre ML-KEM, prend un relief différent : disposer d’un second algorithme mathématiquement indépendant devient un argument de résilience plus concret quand une implémentation du premier se révèle défaillante.
Cinq prévisions pour les prochains mois
D’autres bogues d’implémentation ML-KEM vont probablement émerger. À mesure que davantage de bibliothèques accélèrent leur code post-quantique pour rivaliser en performance avec RSA, la surface d’erreur augmente mécaniquement, un risque que les agences du G7 ont explicitement anticipé dans leur appel de septembre.
Les certifications ANSSI vont intégrer des critères d’audit d’implémentation, pas seulement de choix d’algorithme. L’échéance 2027 pourrait s’accompagner d’exigences plus précises sur les tests de conformité aux vecteurs de test officiels ML-KEM.
wolfSSL devrait publier un audit renforcé de son code AVX2 pour les autres tailles de clés ML-KEM-512 et ML-KEM-768. Une faille localisée sur une variante appelle presque toujours une revue de sécurité des variantes voisines du même algorithme.
La demande d’audits tiers spécialisés en cryptographie post-quantique va augmenter chez les intégrateurs européens de l’IoT et de l’automobile. Les équipementiers qui certifient leurs produits pour le marché régulé français n’auront plus le choix face à la pression réglementaire.
Le délai entre correctif amont et déploiement dans les distributions Linux et les firmwares embarqués restera le maillon faible de la chaîne. Le cas des paquets Debian toujours non corrigés plusieurs mois après la publication de wolfSSL 5.9.2 ne devrait pas rester isolé tant que la gestion des dépendances tierces ne sera pas automatisée plus largement.
Questions fréquentes
Qu’est-ce que CVE-2026-10097 exactement ?
C’est une faille dans l’implémentation accélérée AVX2 de ML-KEM-1024 chez wolfSSL. Une fonction de comparaison ne vérifie que 1 536 des 1 568 octets d’un texte chiffré, ce qui permet à un attaquant de forger des requêtes et de reconstituer une clé privée complète en environ 350 tentatives.
ML-KEM lui-même est-il cassé ?
Non. La faille touche uniquement une implémentation logicielle spécifique, pas la construction mathématique de ML-KEM validée par le NIST sous FIPS 203. Aucune faiblesse n’a été signalée dans les implémentations d’OpenSSL, de BoringSSL ou de liboqs.
Quelles versions de wolfSSL sont concernées ?
Les versions 5.7.0 à 5.9.1 sont affectées par CVE-2026-10097. CVE-2026-11310 touche spécifiquement les versions 5.8.4, 5.9.0 et 5.9.1 compilées avec l’option de compatibilité OpenSSL. Les deux failles sont corrigées dans la version 5.9.2.
La faille est-elle exploitée activement ?
Aucune source publique consultée ne signale d’exploitation confirmée en conditions réelles à la mi-septembre 2026. Les bases de vulnérabilités recommandent néanmoins d’appliquer le correctif sans attendre, compte tenu de la disponibilité d’une preuve de concept documentée.
Comment savoir si mon appareil utilise wolfSSL ?
La bibliothèque est souvent intégrée directement dans le firmware par le fabricant, sans mention visible côté utilisateur final. Les équipes techniques peuvent vérifier les nomenclatures logicielles (SBOM) du produit ou contacter le fournisseur pour connaître la bibliothèque TLS utilisée et sa version.
Faut-il régénérer les clés après avoir appliqué le correctif ?
C’est recommandé pour toute clé ML-KEM-1024 statique qui a pu être exposée à des connexions provenant de sources non authentifiées avant la mise à jour, puisqu’une clé potentiellement compromise avant le correctif n’est pas protégée rétroactivement par le seul fait de mettre à jour le logiciel.
Cette affaire remet-elle en cause le calendrier post-quantique de l’ANSSI ?
Non, mais elle renforce l’argument selon lequel les futures certifications devront porter sur la qualité des implémentations et pas seulement sur le choix de l’algorithme, un point que les autorités françaises et le G7 ont explicitement mis en avant début septembre 2026.
Où trouver l’avis officiel de wolfSSL ?
L’éditeur publie ses avis de sécurité sur sa page dédiée aux vulnérabilités, qui référence les identifiants CVE, les versions affectées et les correctifs disponibles pour chaque faille.
