Faille de l’app Ethereum de Ledger : l’écran pouvait afficher une transaction et en signer une autre

Une faille de l’app Ethereum de Ledger concernait certains scénarios de signature claire (« clear signing »). Elle pouvait permettre à une dApp malveillante de remplacer les données d’une transaction pendant que l’utilisateur vérifiait la demande d’origine. Dans le scénario redouté, l’écran du Ledger continuait d’afficher des informations légitimes alors que l’appareil signait une autre requête. 39

Ledger affirme que son équipe de sécurité Donjon avait identifié et corrigé le problème avant sa divulgation publique par TestMachine. Le correctif a été intégré à l’app Ethereum 1.22.2, publiée le 12 août 2026, tandis que TestMachine a commencé à publier ses conclusions le 21 août. 569

Comment fonctionnait l’attaque par substitution de signature

Le problème concernait les commandes APDU — les messages échangés entre l’ordinateur, le navigateur ou la dApp connectée et l’application Ethereum du Ledger. Lors d’une signature claire normale, l’appareil reçoit les données de la transaction, affiche les éléments importants à vérifier, puis attend la validation de l’utilisateur.

D’après les recherches rapportées, un site ou une dApp malveillante disposant d’un accès WebHID pouvait envoyer une deuxième commande APDU alors que la première transaction était encore affichée à l’écran. Une course se créait alors entre deux demandes de signature. Le flux vulnérable ne liait pas suffisamment la transaction affichée à une session de signature unique et immuable, ouvrant la voie à une substitution. 3715

Le risque ne se limitait donc pas à l’échec d’une transaction. L’utilisateur pouvait voir une opération anodine et l’approuver, tandis que l’appareil signait finalement une autorisation de jetons, un transfert ou une autre demande malveillante. Cela remettait en cause l’objectif même de la signature claire : vérifier les détails de la transaction directement sur le portefeuille matériel avant de l’autoriser. 110

Ce que corrige la version 1.22.2

La mise à jour de l’app Ethereum corrige le flux de signature concerné. Les changements techniques rapportés indiquent que la version 1.22.2 empêche une nouvelle session de remplacer une session déjà en cours de vérification et rejette le retour de validation lorsque l’état de l’application ne correspond plus à la demande active. 10

Charles Guillemet, directeur technique de Ledger, a déclaré que l’équipe Donjon avait découvert la vulnérabilité à l’aide d’outils de détection assistés par IA et déployé le correctif le 12 août. Les comptes rendus disponibles décrivent des notes de version très succinctes, mentionnant simplement des problèmes de sécurité plutôt qu’un avis détaillé. 356

Cette nuance est importante pour les utilisateurs. Installer la nouvelle version protège le processus de signature pour les opérations futures, mais un changelog minimal laisse les propriétaires d’appareils avec peu d’informations sur la nature du changement ou sur l’urgence de la mise à jour.

La divulgation de TestMachine et d’Azimuth

TestMachine a indiqué que son agent IA, Azimuth, avait découvert la faille lors d’une analyse autonome. L’entreprise affirme avoir validé le comportement sur un Ledger Flex. Dans des publications diffusées du 21 au 23 août, elle a décrit la manière dont une dApp malveillante pouvait lancer une commande APDU concurrente pendant la vérification d’une transaction. TestMachine a présenté le problème comme touchant tous les appareils Ledger exécutant l’app Ethereum. 4715

Cette divulgation a attiré l’attention sur une vulnérabilité que Ledger affirme avoir déjà corrigée. TestMachine a également déclaré avoir refusé une prime de sécurité, tandis que Ledger conteste le déroulement des échanges autour de cette divulgation. 1612

Ledger et TestMachine s’opposent sur la chronologie

Le désaccord porte principalement sur la découverte privée et le processus de divulgation, et non sur l’existence du correctif.

Selon la version de Ledger, l’équipe Donjon a découvert la faille, l’a corrigée et a publié la mise à jour environ deux semaines avant les révélations publiques de TestMachine. Charles Guillemet a critiqué la communication ultérieure, estimant qu’elle avait provoqué une inquiétude inutile alors que le problème était déjà traité. 6712

TestMachine affirme de son côté qu’Azimuth a découvert et validé la vulnérabilité de manière indépendante. L’entreprise reproche à Ledger de ne pas avoir véritablement alerté ses utilisateurs lorsque le correctif a été publié discrètement. Ses messages publics ont insisté sur le scénario d’attaque et sur l’étendue de sa revendication. 715

Les informations disponibles étayent la date du correctif — le 12 août — ainsi que les dates des publications publiques, du 21 au 23 août. Elles ne permettent pas d’établir indépendamment les dates exactes des découvertes privées, les échanges entre les deux équipes ni une chronologie complète. Ces éléments doivent donc être considérés comme des versions concurrentes plutôt que comme des faits définitivement établis. 56912

Quels appareils Ledger pourraient être concernés ?

La revendication générale de TestMachine repose sur du code Ethereum et de signature partagé, mais la validation pratique rapportée a été réalisée sur un Ledger Flex. Les familles d’appareils modernes susceptibles de partager le code concerné comprennent notamment les Nano S Plus, Nano X, Stax et Flex. 2720

Cela ne constitue pas une preuve complète et documentée de l’exploitation sur chaque modèle Ledger. Au 24 août, l’affirmation selon laquelle « tous les Ledger » seraient concernés restait une déclaration de chercheur, et non un résultat reproduit sur l’ensemble des gammes. Il faut distinguer un chemin logiciel potentiellement commun d’un exploit démontré publiquement sur chaque appareil.

Des fonds ont-ils été volés ?

Au 24 août 2026, aucun vol de fonds lié spécifiquement à cette vulnérabilité n’avait été vérifié de manière indépendante. Aucune démonstration publique complète couvrant tous les appareils Ledger visés n’avait non plus été confirmée. 25614

Cela décrit l’état des éléments disponibles à cette date et ne prouve pas que la faille n’a jamais été exploitée. Elle était sérieuse parce qu’elle pouvait contourner la vérification de transaction sur laquelle les utilisateurs comptent, même si aucun préjudice financier confirmé n’apparaissait dans les informations disponibles.

Ce que les utilisateurs de Ledger doivent faire

Ouvrez Ledger Live et mettez à jour l’app Ethereum vers la version 1.22.2 ou une version ultérieure. Maintenez également le firmware du Ledger et les autres applications installées à jour. Pour cette faille de substitution lors de la signature, la mesure corrective pertinente est la mise à jour de l’app Ethereum — et pas seulement celle du firmware. 515

Après la mise à jour, la vérification sur l’appareil reste indispensable : contrôlez le destinataire, le montant et l’action du contrat affichés sur le Ledger avant d’approuver une transaction. La mise à jour corrige le chemin de substitution décrit dans les rapports, mais une lecture attentive des détails affichés demeure une bonne pratique de sécurité.