Un octet. C’est tout ce qu’il fallait pour tromper une bibliothèque de cryptographie utilisée dans l’écosystème OCaml et MirageOS. Le 9 septembre 2026, une faille référencée CVE-2026-87733 a été rendue publique dans mirage-crypto-ec, le module de cryptographie à courbe elliptique du projet MirageOS. Elle permet de forger des signatures ECDSA valides sans jamais posséder la clé privée correspondante. Le correctif est sorti en moins de 24 heures, mais l’affaire relance un débat qui traverse la cryptographie appliquée depuis des années : pourquoi les bibliothèques continuent-elles d’accepter des clés publiques mathématiquement invalides ?
Ce que dit précisément CVE-2026-87733
La faille touche toutes les versions de mirage-crypto-ec antérieures à la 2.2.0. Elle a été enregistrée sous l’identifiant CVE-2026-87733 dans la base du NIST, avec une entrée miroir sur OSV sous la référence OSEC-2026-13. Les fonctions concernées sont {P256,P384,P521}.Dsa.pub_of_octets, c’est-à-dire les routines chargées d’analyser une clé publique ECDSA encodée en octets avant de vérifier une signature. Les trois courbes du standard NIST, P-256, P-384 et P-521, sont toutes affectées de la même manière.
Le score attribué est un CVSS v3.1 de 6,2, classé “moyen”. À première vue, ce chiffre paraît modeste pour un bug qui casse l’intégrité même d’une signature numérique. La raison tient au vecteur d’attaque retenu par les analystes : l’exploitation suppose un accès local non authentifié à l’application qui consomme la clé publique malformée, ce qui limite le rayon d’action par rapport à une faille exploitable à distance sur Internet. Mais dans un contexte où une bibliothèque signe des mises à jour, des transactions ou des identités machine, un accès local suffit souvent à faire beaucoup de dégâts.
MirageOS et mirage-crypto-ec : à quoi sert cette bibliothèque
MirageOS est un projet de “library operating system” écrit en OCaml : au lieu de faire tourner une application sur un système d’exploitation généraliste, on compile un exécutable spécialisé, un unikernel, qui n’embarque que le strict nécessaire. L’objectif est de réduire la surface d’attaque et la consommation mémoire. mirage-crypto-ec fournit la brique de cryptographie à courbe elliptique de cette pile : signatures ECDSA, échanges de clés ECDH, et primitives associées, sans dépendre des liaisons OpenSSL classiques.
Le projet est maintenu dans l’orbite de Tarides, une société qui emploie plusieurs contributeurs historiques de l’écosystème OCaml. Parmi les usages documentés, le fabricant allemand de clés de sécurité Nitrokey s’appuie sur des briques MirageOS pour une partie de ses travaux sur les modules matériels de sécurité (HSM). OCaml reste un langage de niche comparé à Python ou JavaScript, mais il irrigue des secteurs où la correction du code prime sur la popularité : compilateurs, outils de preuve formelle, et systèmes embarqués à contrainte de sécurité forte. C’est précisément ce public exigeant qui a repéré puis corrigé la faille en un temps record.
Le piège du point à l’infini
Pour comprendre le bug, il faut revenir à la base de la cryptographie à courbe elliptique. Une clé publique ECDSA est un point sur une courbe, défini par deux coordonnées. Mais les mathématiques des courbes elliptiques définissent aussi un point spécial, appelé point à l’infini, qui sert d’élément neutre pour l’addition de points. Ce point n’a pas de coordonnées classiques et ne doit jamais être accepté comme une clé publique valide, car il rend la vérification de signature triviale à contourner.
Dans les formats d’encodage standards, ce point à l’infini est représenté par un seul octet : 0x00. La routine pub_of_octets de mirage-crypto-ec, avant la version 2.2.0, acceptait cet octet unique comme une clé publique légitime au lieu de le rejeter. Selon la fiche technique publiée sur OSV, le chemin Diffie-Hellman de la même bibliothèque, lui, rejetait déjà correctement ce cas particulier. C’est cette incohérence entre deux routines censées appliquer la même règle de validation qui a laissé la porte ouverte côté signatures.
Comment un octet permet de forger une signature
Une fois qu’un vérificateur accepte le point à l’infini comme clé publique, les équations de vérification ECDSA dégénèrent. Un attaquant qui connaît la clé publique déclarée (mais falsifiée à 0x00) peut alors construire une paire message-signature qui passera la vérification sans jamais avoir eu accès à une clé privée. Le système croit valider l’authenticité d’un message alors qu’il ne valide rien du tout. C’est le scénario redouté dans toute chaîne de confiance basée sur la signature ECDSA : mise à jour logicielle, jeton d’authentification machine, ou preuve d’intégrité d’un firmware.
(* Comportement fautif avant mirage-crypto-ec 2.2.0 *)
let pub_of_octets bytes =
(* 0x00 encode le point a l'infini, jamais une cle valide *)
if bytes = "\x00" then
Ok infinity_point (* accepte a tort *)
else
parse_normal_point bytes
(* Comportement corrige en 2.2.0 *)
let pub_of_octets bytes =
if bytes = "\x00" then
Error `Invalid_public_key (* rejete, comme sur le chemin ECDH *)
else
parse_normal_point bytesUne réponse des mainteneurs en moins d’une journée
D’après les horodatages publics de la fiche NVD et de l’entrée OSV, la vulnérabilité a été publiée le 9 septembre 2026 et l’entrée de suivi était déjà mise à jour avec le statut corrigé dès le lendemain. Le correctif consiste à faire rejeter explicitement l’octet 0x00 par les trois routines pub_of_octets, en alignant le comportement du chemin de signature sur celui, déjà correct, du chemin d’échange de clés. La recommandation est simple : mettre à jour vers mirage-crypto-ec 2.2.0 ou une version ultérieure. Aucune preuve de concept publique n’a circulé au moment de la divulgation, et rien n’indique une exploitation active. La faille reste, à ce stade, un risque théorique mais réel plutôt qu’une campagne d’attaque documentée.
Cette rapidité de correction tranche avec certains cas où des bibliothèques cryptographiques historiques traînent des failles connues pendant des années avant qu’un correctif ne sorte, comme cela avait été documenté pour Libgcrypt et une faille RSA restée ouverte près d’une décennie. Ici, la taille réduite de la communauté OCaml a probablement joué en faveur d’une réaction rapide : moins de code à auditer, des mainteneurs identifiés, et un écosystème habitué aux revues de code strictes propres au langage.
Un air de déjà-vu : le précédent Java de 2022
Les praticiens de la cryptographie ont vite fait le lien avec un précédent célèbre : CVE-2022-21449, surnommée à l’époque “Psychic Signatures”, découverte dans l’implémentation ECDSA du JDK d’Oracle. Le principe racine était similaire : la vérification de signature acceptait des valeurs qui auraient dû être rejetées, ce qui permettait de forger des signatures sans clé privée. La différence tient à l’ampleur de l’exposition. Le bug Java se trouvait dans une bibliothèque standard utilisée par un nombre colossal d’applications d’entreprise, ce qui en avait fait, dans les faits, une faille critique malgré une notation officielle parfois plus mesurée. Le bug mirage-crypto-ec touche un écosystème beaucoup plus restreint, mais souvent déployé dans des contextes à fort enjeu de sécurité, comme les modules matériels ou les unikernels de production.
Ce n’est pas non plus la première fois qu’une chaîne d’implémentations ECC bute sur la validation des points spéciaux d’une courbe. Une vague de failles touchant Linux, Python et OP-TEE avait déjà mis en évidence, plus tôt cette année, que la validation de clé publique en cryptographie à courbe elliptique reste un point faible récurrent des implémentations, tous langages confondus.
Comparaison technique entre les deux failles
| Critère | CVE-2026-87733 (mirage-crypto-ec) | CVE-2022-21449 (Java ECDSA) |
|---|---|---|
| Date de divulgation | 9 septembre 2026 | 19 avril 2022 |
| Langage / plateforme | OCaml, écosystème MirageOS | Java (JDK 15, 18, 19 concernés) |
| Cause racine | Acceptation du point à l’infini (octet 0x00) comme clé publique | Acceptation de signatures dégénérées lors de la vérification |
| Conséquence | Forgerie de signature ECDSA sans clé privée | Forgerie de signature ECDSA sans clé privée |
| Score de sévérité | CVSS v3.1 : 6,2 (moyen) | Classée critique dans la pratique par de nombreux analystes |
| Correctif | mirage-crypto-ec 2.2.0 | Mise à jour JDK 15.0.7 / 18.0.2.1 / 19.0.2 et suivantes |
| Exploitation constatée | Aucune preuve publique à la divulgation | Aucune exploitation massive documentée publiquement |
Pourquoi la note CVSS sous-estime souvent ce type de bug
Le CVSS mesure des critères techniques précis : vecteur d’attaque, complexité, privilèges requis, interaction utilisateur, puis les impacts sur la confidentialité, l’intégrité et la disponibilité. Pour CVE-2026-87733, l’exigence d’un accès local fait mécaniquement baisser la note, alors que l’impact sur l’intégrité, lui, est maximal : une fois la clé forgée acceptée, la vérification de signature devient une coquille vide. C’est ce décalage entre score numérique et gravité fonctionnelle qui alimente régulièrement les débats entre équipes sécurité et équipes produit sur la priorité réelle à donner à un correctif.
Dans la pratique, un attaquant capable d’obtenir un accès local, par exemple via un conteneur partagé, une chaîne CI/CD compromise ou un poste de développeur infecté, pourrait exploiter cette faille pour faire signer un artefact malveillant comme s’il provenait d’une source légitime. Le risque est donc moins un scénario de piratage massif à distance qu’un vecteur de mouvement latéral et de compromission de la chaîne d’approvisionnement logicielle, une catégorie de menace prise très au sérieux depuis les multiples révocations de certificats de signature de code observées cette année, dont celle touchant DigiCert et 60 certificats de signature.
Chronologie de la divulgation
| Date | Événement |
|---|---|
| Avant le 9 septembre 2026 | Découverte de l’incohérence entre les chemins ECDSA et ECDH dans mirage-crypto-ec |
| 9 septembre 2026 | Publication de CVE-2026-87733 sur la base NIST |
| 9-10 septembre 2026 | Entrée miroir OSEC-2026-13 publiée sur OSV avec description technique complète |
| 10 septembre 2026 | Statut “corrigé” confirmé, version 2.2.0 disponible |
| 15 septembre 2026 | Aucune preuve de concept publique ni exploitation confirmée à ce jour |
Fonctions et courbes concernées
- P256.Dsa.pub_of_octets : acceptait l’octet 0x00 comme clé publique valide avant la version 2.2.0
- P384.Dsa.pub_of_octets : même défaut de validation sur la courbe P-384
- P521.Dsa.pub_of_octets : même défaut de validation sur la courbe P-521
- Chemin Diffie-Hellman (ECDH) : non affecté, le rejet du point à l’infini y était déjà correctement implémenté
Le contexte plus large : l’ECC sous surveillance en 2026
CVE-2026-87733 arrive dans une année où la cryptographie à courbe elliptique concentre une attention inhabituelle. Entre les recommandations de l’ANSSI sur l’hybridation post-quantique, la publication des standards ML-KEM et ML-DSA par le NIST, et une série de CVE touchant des implémentations de signatures, comme la faille de signature SSH corrigée dans RouterOS plus tôt cette année, les équipes sécurité passent au crible des bibliothèques qui n’avaient pas fait l’objet d’un audit depuis longtemps. Ce climat de vigilance accrue explique en partie pourquoi une bibliothèque aussi confidentielle que mirage-crypto-ec attire l’attention de la presse spécialisée alors que son empreinte réelle reste modeste.
Cette tendance dépasse la seule signature ECDSA. Les mécanismes de transparence des certificats basés sur les arbres de Merkle et les schémas hybrides classique-post-quantique poussent les développeurs à revisiter des routines de validation écrites il y a parfois plus d’une décennie, à une époque où les modèles de menace étaient différents. Le résultat est mécanique : plus on regarde, plus on trouve, et la cadence de publication de CVE sur des primitives considérées comme matures va probablement continuer à augmenter avant de refluer une fois les grandes bibliothèques nettoyées.
Ce que doivent faire les équipes qui utilisent mirage-crypto-ec
La première étape est mécanique : identifier toute dépendance directe ou transitive à mirage-crypto-ec dans un projet OCaml, via l’outil opam, et vérifier la version installée. Toute version antérieure à 2.2.0 doit être mise à jour sans attendre, en particulier si la bibliothèque sert à vérifier des signatures provenant de sources externes ou non fiables, comme des mises à jour logicielles ou des jetons d’authentification. La seconde étape, souvent négligée, consiste à auditer les journaux d’application pour repérer d’éventuelles tentatives de vérification ayant utilisé une clé publique anormalement courte, ce qui pourrait indiquer une tentative d’exploitation passée.
Pour les équipes qui conçoivent leurs propres routines de validation ECC, qu’elles soient en OCaml, en Go ou en Rust, la faille rappelle une règle de base souvent oubliée sous la pression des délais : toute désérialisation de clé publique doit explicitement rejeter le point à l’infini et vérifier l’appartenance du point à la courbe attendue, avant toute autre opération. Un test unitaire dédié à ce cas précis, à l’image de ce qui existe déjà pour l’implémentation Ed25519 comparée à ECDSA P-256, coûte quelques lignes de code et évite ce type de régression.
Impact sur le marché et l’écosystème OCaml
Il serait exagéré de parler d’un choc de marché : OCaml reste un langage de niche, loin des volumes de déploiement de Java ou de C. Mais l’incident illustre un phénomène plus large observé cette année dans la cryptographie appliquée. Les bibliothèques qui gagnent en adoption dans des contextes à fort enjeu, comme les modules matériels de sécurité, les unikernels d’infrastructure ou les environnements d’exécution de confiance, deviennent des cibles d’audit prioritaires précisément parce que leur compromission a un effet démultiplié. Une clé mal validée dans une brique de signature de firmware, par exemple, peut affecter des milliers d’appareils déployés avec un seul correctif raté.
Pour les entreprises qui misent sur MirageOS pour ses promesses de surface d’attaque réduite, l’épisode envoie un signal ambivalent. D’un côté, la rapidité de la correction, moins de 24 heures entre la divulgation publique et la disponibilité d’un correctif, démontre la réactivité d’une communauté de taille modeste mais technique. De l’autre, la faille rappelle qu’une base de code plus petite ne garantit pas l’absence de bugs fondamentaux, surtout quand deux chemins de code censés appliquer la même règle de sécurité finissent par diverger silencieusement pendant des années.
Cinq prévisions pour la suite
- D’autres bibliothèques ECC de niche, moins auditées que OpenSSL ou BoringSSL, devraient faire l’objet de révélations similaires dans les prochains mois, à mesure que les chercheurs élargissent leur périmètre de recherche au-delà des piles les plus populaires.
- Les projets critiques comme MirageOS vont probablement renforcer leurs suites de tests de non-régression autour des points spéciaux de courbe, notamment le point à l’infini et les points hors courbe.
- Les outils d’analyse statique dédiés à la cryptographie devraient intégrer des règles automatiques pour détecter les incohérences entre routines de validation, sur le modèle de l’écart observé ici entre les chemins ECDSA et ECDH.
- La pression réglementaire déjà exercée sur les grandes bibliothèques via les audits liés au Cyber Resilience Act va probablement s’étendre aux dépendances de niche utilisées dans des produits certifiés, y compris les briques OCaml embarquées dans du matériel de sécurité.
- Le parallèle avec le bug Java de 2022 va continuer à être cité comme cas d’école dans les formations en cryptographie appliquée, preuve qu’une même classe d’erreur peut réapparaître à des années d’écart dans des langages totalement différents.
Une leçon qui dépasse le seul cas OCaml
Le point commun entre CVE-2026-87733 et son cousin java de 2022 n’est pas un langage ni une bibliothèque, mais une hypothèse implicite trop souvent faite par les développeurs : une donnée qui ressemble à une clé publique valide en est forcément une. La cryptographie à courbe elliptique repose sur des propriétés mathématiques précises, et chaque exception à ces propriétés, comme le point à l’infini, doit être traitée explicitement plutôt que supposée impossible. Ce n’est pas la complexité des courbes elliptiques qui pose problème ici, mais l’absence d’un simple test de rejet à l’entrée d’une fonction critique.
Le code source complet de la bibliothèque reste consultable sur le dépôt GitHub du projet mirage-crypto, où l’historique des correctifs permet à quiconque de comparer les versions avant et après le patch. C’est aussi ce type de transparence, courant dans l’écosystème du logiciel libre, qui a permis une correction aussi rapide une fois le problème identifié.
Foire aux questions
Qu’est-ce que CVE-2026-87733 exactement ?
C’est une vulnérabilité affectant mirage-crypto-ec, la bibliothèque de cryptographie à courbe elliptique du projet OCaml MirageOS, publiée le 9 septembre 2026. Elle permet de forger des signatures ECDSA valides sans posséder la clé privée, à cause d’une mauvaise validation des clés publiques encodées.
Quelles versions de mirage-crypto-ec sont concernées ?
Toutes les versions antérieures à la 2.2.0. La mise à jour vers cette version ou une version plus récente corrige le défaut de validation.
La faille a-t-elle été exploitée dans la nature ?
Aucune preuve de concept publique ni aucune exploitation confirmée n’avait été rapportée au moment de la divulgation. Le risque est décrit comme théorique mais réel, faute de preuve de concept publiée.
Qu’est-ce que le point à l’infini en cryptographie à courbe elliptique ?
C’est un point spécial, sans coordonnées classiques, qui sert d’élément neutre dans l’addition de points sur une courbe elliptique. Il ne doit jamais être accepté comme clé publique valide, car cela rend la vérification de signature contournable.
En quoi cette faille ressemble-t-elle au bug Java “Psychic Signatures” de 2022 ?
Les deux failles, CVE-2026-87733 et CVE-2022-21449, partagent la même conséquence : la possibilité de forger une signature ECDSA valide sans clé privée, à cause d’une acceptation incorrecte d’une valeur qui aurait dû être rejetée lors de la vérification.
Cette faille menace-t-elle Bitcoin ou Ethereum ?
Non. mirage-crypto-ec est une bibliothèque de l’écosystème OCaml MirageOS, sans lien avec les implémentations ECDSA ou secp256k1 utilisées par les grandes blockchains. Le risque est circonscrit aux projets qui dépendent directement de cette bibliothèque.
Mon entreprise n’utilise pas OCaml, dois-je m’inquiéter ?
Le risque direct est limité aux projets utilisant mirage-crypto-ec. En revanche, la leçon technique, toujours rejeter le point à l’infini et valider l’appartenance à la courbe avant de faire confiance à une clé publique, s’applique à toute implémentation ECC, quel que soit le langage utilisé.
Comment savoir si mon projet dépend de mirage-crypto-ec ?
Il suffit de vérifier les dépendances déclarées via le gestionnaire de paquets opam, en recherchant mirage-crypto-ec dans l’arbre de dépendances direct et transitif, puis de comparer la version installée à la version corrigée 2.2.0.
