Imaginez un instant que vous vérifiez minutieusement chaque détail d’une transaction sur l’écran de votre portefeuille matériel, convaincu que ce que vous voyez est exactement ce qui sera signé. Et si, sans le savoir, l’appareil apposait en réalité sa signature sur une opération totalement différente ? C’est précisément le scénario qu’une équipe de sécurité a mis en lumière ces derniers jours, relançant un débat vif entre deux acteurs majeurs du secteur des cryptomonnaies.
Une démonstration en laboratoire qui relance le débat sur la sécurité des portefeuilles matériels
Le 27 août, le fondateur d’OneKey, Yishi Wang, a publié un message affirmant que son équipe Anzen avait réussi à reproduire une attaque de substitution de transaction contre l’application Ethereum de Ledger en version 1.22.1. Dans son ton, il n’a pas hésité à parler de « piratage » réussi. Quelques heures plus tard, Ledger a répondu avec fermeté : reproduire une faille déjà corrigée ne constitue en aucun cas un piratage de ses dispositifs.
Cette confrontation met en lumière un point crucial pour tous les détenteurs de cryptomonnaies. Les portefeuilles matériels reposent sur une promesse simple et forte : l’écran intégré permet de vérifier de façon fiable les montants, adresses et actions avant d’approuver une signature. Lorsque cette garantie est remise en question, même temporairement, la confiance des utilisateurs peut vaciller.
Le mécanisme exact de la vulnérabilité découverte
La faille concernait la communication entre le dispositif Ledger et l’ordinateur ou le navigateur auquel il est connecté. Les applications reçoivent des instructions appelées APDU (Application Protocol Data Unit). Dans certaines conditions, une application vulnérable pouvait accepter une seconde commande pendant que l’utilisateur examinait encore la première opération sur l’écran.
Cette nouvelle commande avait la capacité d’écraser les paramètres de signature stockés en mémoire partagée, sans que l’affichage soit mis à jour. Résultat : l’utilisateur croyait valider la transaction A, alors que l’appareil générait une signature pour la transaction B. Aucune alerte n’informait l’utilisateur du changement survenu en arrière-plan.
Ledger a classé le problème comme une condition de course de type time-of-check to time-of-use. Cette catégorie de vulnérabilité est bien connue en sécurité informatique. Elle casse la protection d’affichage de confiance, élément central de la sécurité des portefeuilles matériels.
Il est important de souligner ce que la faille ne permettait pas. Elle n’extrayait ni la phrase de récupération ni les clés privées du module sécurisé. Elle se limitait à faire signer des paramètres différents de ceux présentés à l’écran.
Les conditions nécessaires pour exploiter la faille
L’attaque n’était pas réalisable à distance contre un appareil débranché. L’attaquant devait contrôler les communications entre le dispositif et son hôte. Ledger a listé plusieurs vecteurs possibles :
Vecteurs d’attaque identifiés :
- Présence de malware sur l’ordinateur de l’utilisateur
- Application de portefeuille compromise
- Page web hostile disposant d’un accès WebHID ou WebUSB
Même dans ces cas, l’utilisateur devait encore approuver physiquement la transaction pendant que le logiciel malveillant manipulait le contexte de signature en attente. Le scénario restait donc relativement complexe à mettre en œuvre à grande échelle.
Le défaut se situait dans la gestion des entrées et sorties du Secure SDK de Ledger, et non dans le système d’exploitation ou le firmware de l’appareil lui-même. Les applications compilées avec les versions concernées du SDK dépendaient de leurs propres vérifications d’état pour rejeter les commandes arrivant pendant une revue active. L’exposition était donc spécifique à chaque application.
La réponse ferme de Ledger et le calendrier des correctifs
Charles Guillemet, directeur technique de Ledger, a contesté directement le langage employé par OneKey. Selon lui, « reproduire un bug déjà corrigé n’est pas pirater Ledger ». Il a présenté le travail d’OneKey comme un exercice de laboratoire réalisé sur une version ancienne de l’application.
Le calendrier des mises à jour apporte un éclairage précis. L’application Ethereum 1.22.2, publiée le 13 août, contenait déjà les premières vérifications d’état destinées à bloquer le chemin de substitution de transaction documenté. Le 21 août, Ledger a ensuite publié le Secure SDK 26.6.1. Cette version empêche les commandes entrelacées d’atteindre directement le code des applications.
Ledger recommande désormais d’utiliser l’application Ethereum 1.22.3 ou une version ultérieure. Cette release intègre la protection plus large apportée par le nouveau SDK et corrige également une autre imperfection d’affichage des transactions. OneKey avait raison de souligner que la version 1.22.3 est protégée, mais le premier correctif applicatif était déjà présent dans la 1.22.2.
Nous n’avons trouvé aucune preuve que cette vulnérabilité ait été exploitée contre des utilisateurs ou ait entraîné des pertes de cryptomonnaies.
Cette déclaration de Ledger rassure en partie, mais elle ne dispense pas les utilisateurs de la vigilance. L’absence de preuves d’exploitation ne signifie pas que le risque était nul pour ceux qui n’avaient pas encore mis à jour leur application.
Ce que les utilisateurs doivent faire immédiatement
La mise à jour des applications sur un portefeuille Ledger ne se fait pas automatiquement. Il faut passer par Ledger Live. Voici les étapes essentielles à suivre :
- Ouvrir Ledger Live et connecter le dispositif
- Installer ou mettre à jour les applications du dispositif
- Vérifier directement sur l’écran de l’appareil que la version de l’application Ethereum est bien 1.22.3 ou supérieure
- Ne pas se contenter d’une mise à jour du firmware : les applications doivent être reconstruites avec le SDK corrigé
Les développeurs tiers doivent également revoir la gestion des états dans leurs propres applications et les recompiler avec le Secure SDK 26.6.1 ou une version plus récente. Ledger a indiqué que la faiblesse avait été introduite en août 2025 et qu’elle concernait les versions du SDK jusqu’à la 26.6.0.
Pourquoi cette affaire dépasse le simple conflit entre deux entreprises
Au-delà de la polémique sur les mots « piratage » ou « reproduction en laboratoire », cet épisode soulève des questions plus profondes. Les portefeuilles matériels constituent aujourd’hui le dernier rempart pour de nombreux investisseurs contre le vol de fonds. Leur sécurité repose en grande partie sur la confiance placée dans l’affichage et dans l’impossibilité pour un logiciel malveillant de tromper l’utilisateur.
Quand une condition de course permet de contourner cet affichage, même de façon temporaire et sous des conditions strictes, cela rappelle que la sécurité est un processus continu et non un état absolu. Les constructeurs doivent corriger rapidement, informer clairement et fournir des outils de mise à jour simples. Les utilisateurs, de leur côté, doivent rester proactifs dans l’application des correctifs.
L’affaire intervient dans un contexte où d’autres fabricants de portefeuilles matériels ont également annoncé des correctifs récents. BitBox, par exemple, a patché deux failles touchant l’installation de firmware et la gestion des adresses Bitcoin, là aussi sans signaler d’exploitation confirmée. Ces annonces successives montrent que le secteur reste sous surveillance constante de la part de chercheurs en sécurité.
Les implications pour la confiance des utilisateurs de longue date
Pour beaucoup de détenteurs de cryptomonnaies, Ledger représente une référence historique. Des millions de dispositifs ont été vendus et sont utilisés quotidiennement pour sécuriser des actifs parfois importants. Une telle faille, même déjà corrigée, peut générer un sentiment d’inquiétude légitime.
Pourtant, la réaction de l’entreprise montre une certaine maturité. Elle a reconnu l’existence de la vulnérabilité, fourni un calendrier précis des correctifs et affirmé n’avoir détecté aucune exploitation réelle. Elle a également précisé que la faille ne permettait pas d’extraire les clés privées, ce qui limite considérablement l’impact potentiel.
OneKey, de son côté, a joué le rôle classique du chercheur en sécurité qui teste et publie. Même si le langage employé a été jugé excessif par Ledger, la démonstration a eu le mérite de forcer une communication claire et de rappeler l’importance des mises à jour régulières.
Comment les conditions de course se glissent dans le code des SDK
Les conditions de course sont particulièrement difficiles à détecter. Elles apparaissent lorsque deux opérations concurrentes accèdent à une ressource partagée sans synchronisation adéquate. Dans le cas présent, l’affichage d’une transaction et la réception d’une nouvelle commande APDU pouvaient interagir de façon imprévue.
Le Secure SDK de Ledger est conçu pour fournir une base commune à de nombreuses applications. Une modification introduite en août 2025 a apparemment ouvert cette fenêtre de vulnérabilité. Les applications qui ne vérifiaient pas correctement leur état interne devenaient alors exposées. Celles qui effectuaient des contrôles rigoureux restaient protégées, même compilées avec le SDK affecté.
Cette particularité montre l’importance de la conception défensive au niveau applicatif. Même lorsqu’un SDK présente une faiblesse, une application bien écrite peut limiter les dégâts. À l’inverse, une application qui fait confiance aveuglément aux couches inférieures devient plus fragile.
Les leçons à retenir pour l’écosystème des cryptomonnaies
Plusieurs enseignements se dégagent de cet épisode. Premier point : la transparence reste essentielle. Quand une faille est découverte, une communication claire sur le calendrier des correctifs et sur les versions concernées aide les utilisateurs à se protéger rapidement.
Deuxième point : les utilisateurs ne doivent jamais considérer qu’un portefeuille matériel est « à jour pour toujours ». Les applications, tout comme le firmware, évoluent. Une mise à jour oubliée peut laisser une fenêtre ouverte pendant plusieurs semaines.
Troisième point : la complexité des attaques reste un frein important. Ici, l’attaquant devait déjà contrôler l’hôte de l’utilisateur. Cela ne rend pas la faille anodine, mais cela limite le nombre de personnes réellement exposées à un risque immédiat.
Enfin, la collaboration – même conflictuelle – entre constructeurs et chercheurs en sécurité contribue à renforcer l’ensemble du secteur. Chaque démonstration publique, chaque correctif publié, réduit un peu plus la surface d’attaque disponible pour les acteurs malveillants.
Un regard plus large sur la sécurité des dispositifs de signature
Les portefeuilles matériels ne sont pas les seuls à devoir gérer des problèmes de confiance dans l’affichage. Les applications de signature mobile, les extensions de navigateur et même certains services d’échange confrontent régulièrement les utilisateurs à des interfaces qui doivent rester fiables. Toute faille permettant de tromper l’utilisateur sur ce qu’il signe représente une menace sérieuse.
Dans le cas de Ledger, la présence d’un écran physique et d’un module sécurisé offre une couche de protection supplémentaire. C’est précisément cette couche qui a été partiellement contournée par la condition de course. La rapidité avec laquelle le correctif a été déployé montre que les équipes de sécurité ont pris le sujet au sérieux.
Il reste néanmoins utile de rappeler que la sécurité absolue n’existe pas. Les utilisateurs avertis multiplient les précautions : vérification des adresses sur plusieurs supports, utilisation de comptes séparés pour les opérations courantes et les réserves, et mise à jour systématique des logiciels.
Que retenir de la polémique sémantique autour du mot « piratage »
Le choix des mots n’est jamais anodin dans le domaine de la cybersécurité. Quand un chercheur annonce avoir « piraté » un dispositif, cela attire immédiatement l’attention des médias et des utilisateurs. Quand l’entreprise répond qu’il s’agit d’une simple reproduction en laboratoire d’une faille déjà corrigée, elle cherche à rassurer et à recentrer le débat sur les faits techniques.
Les deux positions ont leur logique. OneKey a voulu souligner la gravité potentielle de la vulnérabilité et la réussite de sa démonstration. Ledger a voulu éviter une panique inutile et rappeler que le correctif était déjà disponible. Au final, l’utilisateur a besoin des deux informations : la nature exacte du risque et les actions concrètes à entreprendre.
Cette tension entre recherche offensive et communication défensive est classique. Elle se retrouve dans de nombreux domaines technologiques. L’essentiel est que les utilisateurs finissent par disposer d’informations claires et actionnables.
Perspectives pour les prochains mois
Il est probable que d’autres équipes de sécurité continueront à tester les différentes versions des applications Ledger et de ses concurrents. Chaque nouvelle découverte, même mineure, contribuera à renforcer les défenses. Les constructeurs, de leur côté, devront maintenir un rythme de correctifs élevé et améliorer encore les mécanismes de protection contre les conditions de course.
Pour les utilisateurs, le message reste simple. Ouvrir régulièrement Ledger Live, installer les dernières versions des applications et vérifier les numéros de version affichés sur l’écran de l’appareil constituent les meilleurs gestes de prévention. La faille décrite ici n’a, selon Ledger, entraîné aucune perte connue. Mais la prochaine pourrait être différente.
Dans un écosystème où les montants en jeu peuvent être considérables, la vigilance collective reste le meilleur rempart. Les démonstrations en laboratoire, même lorsqu’elles suscitent des échanges vifs, participent à cette vigilance. Elles forcent les entreprises à rester transparentes et les utilisateurs à rester informés.
La suite de cette histoire se jouera probablement dans les prochaines semaines, lorsque de nouveaux rapports de sécurité ou de nouvelles mises à jour verront le jour. En attendant, ceux qui détiennent des actifs sur un dispositif Ledger ont tout intérêt à vérifier dès aujourd’hui que leur application Ethereum affiche bien une version 1.22.3 ou supérieure. Un geste simple qui ferme définitivement la fenêtre ouverte par cette condition de course.
La sécurité des cryptomonnaies n’est jamais un acquis. Elle se construit jour après jour, correctif après correctif, et repose autant sur la qualité du code que sur la discipline des utilisateurs. Cet épisode entre OneKey et Ledger en offre une illustration concrète et récente.
