Le 27 août 2026, Yishi Wang, fondateur de OneKey – fabricant de portefeuilles matériels et développeur de l'application OneKey App – a déclaré sur le réseau social X que l'équipe OneKey Anzen a réussi, en laboratoire, à réaliser une attaque par substitution de transaction sur l'application Ethereum Ledger version 1.22.1. Le 27 août 2026, Donjon, une filiale de Ledger, a répondu sur le même réseau qu'aucun utilisateur de portefeuilles matériels n'avait été affecté, et que ce qui était décrit était une démonstration en laboratoire d'une vulnérabilité déjà corrigée.
Selon Wang, le problème identifié est une condition de concurrence entre la logique d'affichage de la transaction sur l'écran de l'appareil et le tampon de la transaction elle-même. Un attaquant obtient la possibilité de réécrire une transaction en attente de signature au moment où l'utilisateur examine l'opération légitime sur l'écran. En fin de compte, la transaction A s'affiche à l'écran, l'utilisateur la confirme, mais l'appareil signe en réalité une toute autre transaction B qu'il n'a pas vue. Pour vérifier l'attaque, l'équipe de OneKey a elle-même compilé le fichier ELF de la version 1.22.1. Wang a noté que Ledger avait corrigé la vulnérabilité dans la version 1.22.3 de l'application, et a recommandé aux propriétaires de versions plus anciennes de se mettre à jour.
Dans les commentaires de la communauté sous son post, il est précisé que l'erreur trouvée correspond à la vulnérabilité divulguée publiquement le 22 août 2026 par le chercheur TestMachine, et que Ledger l'avait déjà corrigée dans la version 1.22.2, et non 1.22.3.
Ce qu'a raconté TestMachine
Le chercheur TestMachine a rapporté le 22 août 2026 avoir découvert la vulnérabilité grâce à l'outil d'analyse automatique hors ligne Azimuth lors d'un audit de l'application Ethereum Ledger. L'erreur a été confirmée sur l'appareil Flex, et le code de traitement des commandes APDU et de l'interface, partagé par les modèles Nano X, Nano S Plus, Stax et Apex, était également concerné. Au moment de la publication, la version corrigée 1.22.2 n'était pas encore publiée. Deux jours plus tard, le 24 août, TestMachine a constaté la publication de la version 1.22.2 sur GitHub avec la note « Security issues » et a conseillé de mettre à jour l'application via Ledger Live.
La position de Ledger Donjon
Selon Donjon, aucun cas de piratage d'utilisateurs réels n'a été enregistré. Le problème a été découvert dans le cadre du processus de sécurité interne et corrigé dans la version 1.22.2, publiée le 13 août 2026, c'est-à-dire avant même la publication du post de OneKey. La société n'a trouvé aucune preuve d'exploitation dans des conditions réelles. Il est recommandé aux utilisateurs de mettre à jour leurs applications vers la dernière version, et l'application Ethereum vers au moins la version 1.22.3, via Ledger Wallet, en vérifiant séparément la version exacte de l'application sur l'appareil lui-même.
Le bulletin officiel LSB 023
Le bulletin de sécurité officiel de Ledger publié le 27 août 2026, sous le numéro LSB 023, décrit la classe de vulnérabilité : pendant que l'utilisateur examinait l'opération à l'écran, l'appareil hôte pouvait envoyer une nouvelle commande APDU par-dessus la précédente non encore traitée, ce qui permettait de modifier les paramètres de signature après qu'ils aient été montrés à l'utilisateur, mais avant la signature effective. Le défaut se situe dans le traitement des entrées/sorties du Ledger Secure SDK, et non dans le système d'exploitation de l'appareil ou le micrologiciel.
La correction a été déployée en deux étapes :
- au niveau des applications individuelles – la version Ethereum 1.22.2, sortie le 13 août 2026, a été la première mise à jour ;
- au niveau du SDK lui-même – la version v26.6.1 est sortie le 21 août 2026, après quoi les applications ont été recompilées avec le framework mis à jour.
La société souligne que la mise à jour du seul micrologiciel n'est pas suffisante – les utilisateurs doivent mettre à jour les applications elles-mêmes via Ledger Live. Ledger répète qu'aucune preuve d'exploitation de la vulnérabilité contre des utilisateurs n'a été trouvée.
Chronologie des versions sur GitHub
Dans le dépôt GitHub LedgerHQ/app-ethereum, il est indiqué que la version 1.22.2 est datée du 24 août 2026 avec la note « Security issues », et que la version 1.22.3, datée du 26 août 2026, inclut un certain nombre de corrections supplémentaires liées au mécanisme de « clear-signing » et à d'autres chemins de traitement des transactions.
La différence d'évaluation entre OneKey et Ledger Donjon s'est réduite à la version dans laquelle le bogue a été corrigé : 1.22.2 contre 1.22.3. Les deux parties s'accordent sur le fait que les utilisateurs doivent mettre à jour l'application Ethereum vers la dernière version via Ledger Live.
L'avis de l'IA
Du point de vue de l'analyse automatisée des données, la controverse autour de la version 1.22.2 contre 1.22.3 est moins importante que la classe de l'erreur trouvée elle-même – une condition de concurrence entre l'affichage à l'écran et la signature effective de la transaction. Une logique similaire est vulnérable non seulement dans les applications Ledger : un problème similaire de chaîne de confiance s'est manifesté dans d'autres portefeuilles matériels, où un défaut au niveau du générateur de nombres aléatoires dans le portefeuille Coldcard a conduit à des clés prévisibles et à des pertes de centaines de millions de dollars. La situation démontre un principe général : la sécurité d'un portefeuille matériel ne repose pas sur un seul maillon – micrologiciel, SDK ou application – mais sur l'ensemble de la chaîne de composants simultanément, et une rupture dans l'un d'eux invalide les autres protections.
Une nuance technique restée hors champ de la discussion : les cycles de mise à jour distincts pour les applications et le SDK, comme dans le cas de l'application Ethereum et du Ledger Secure SDK, créent une fenêtre dans laquelle une partie de l'écosystème est déjà protégée et une autre ne l'est pas encore. Que se passera-t-il si de telles fenêtres commencent à être trouvées plus rapidement que les fabricants ne parviennent à les fermer ?
