Ledger corrige une faille de l'appli Ethereum pouvant provoquer des signatures de transactions incohérentes

Les utilisateurs d'un portefeuille Ledger qui gèrent de l'Ether ou des jetons ERC20 devraient ouvrir Ledger Live et vérifier la version de l'application Ethereum installée sur l'appareil. Toute version antérieure à 1.22.2 ne contient pas un correctif de sécurité essentiel. Ce correctif répare une faille qui s'attaque à la promesse centrale d'un hardware wallet : l'écran doit afficher exactement ce qui va être signé. L'affaire a été rendue publique le 24 août 2026, après la publication d'une analyse par la société de sécurité TestMachine. Le correctif existait déjà à cette date, ce qui a déclenché un désaccord sur la paternité de la découverte et sur le calendrier de diffusion par Ledger. Pour les détenteurs, l'enjeu est surtout pratique : vérifier la version installée et se demander quelles autorisations ont pu être accordées par le passé. Ce qui s'est passé, concrètement La faille ne concerne ni le firmware du périphérique, ni la garde de la clé privée. Elle se situe dans l'application Ethereum, c'est-à-dire le module installé sur l'appareil pour signer des opérations Ether et ERC20. Cette application prépare la transaction, l'affiche à l'écran, puis attend votre confirmation. Dans les versions vulnérables, cet enchaînement pouvait être perturbé : une application web malveillante disposant déjà d'un accès au Ledger connecté pouvait envoyer une seconde demande de signature pendant que la première transaction restait affichée, en attente de validation. L'application échangeait alors les données en mémoire sans réafficher un nouvel écran de vérification. Résultat : l'écran continuait de montrer une opération "inoffensive", mais la confirmation s'appliquait à des données différentes. Selon les chercheurs, le scénario a pu être reproduit de manière démontrable sur un Ledger Flex. Les appareils partageant largement le code de l'application Ethereum, les Nano X, Nano S Plus, Stax et Apex sont également considérés comme potentiellement exposés. Ledger n'a pas indiqué à partir de quelle version l'erreur a été introduite ; la comparaison des chercheurs démarre à la version 1.22.1, précédente version taguée, datée du 27 mai 2026. "Clear signing" : pourquoi l'écran est l'argument clé Le "clear signing" consiste à afficher en clair sur l'écran du portefeuille matériel les données complètes de la transaction avant validation : adresse du destinataire, montant, et, pour les appels de contrats, l'action attendue. C'est le principe qui rend un hardware wallet utile : même si l'ordinateur est compromis, si le navigateur affiche une interface manipulée ou si le site est frauduleux, l'écran indépendant de l'appareil permet de repérer une incohérence avant d'appuyer sur "confirmer". La clé privée ne quitte pas l'appareil ; celui-ci signe localement. La faille frappe précisément ce chaînon : la clé restait protégée, le firmware n'était pas touché, mais un consentement différent de celui affiché pouvait être donné. Si l'écran ne peut plus être considéré comme une source fiable, le gain de sécurité par rapport à un wallet logiciel sur machine infectée se réduit fortement. Le cœur technique : condition de course et commandes APDU Une "race condition" (condition de course) apparaît lorsque le résultat dépend de l'ordre de traitement de commandes quasi simultanées. Le code peut sembler correct dans la plupart des cas et ne dysfonctionner que lorsqu'un attaquant orchestre l'ordre d'exécution. Les portefeuilles matériels échangent avec l'ordinateur via des commandes APDU, un format utilisé par les smart cards. Une signature se déroule en plusieurs étapes APDU. L'application Ethereum maintenait un état indiquant quelle transaction était en cours de vérification. Cet état pouvait être écrasé alors que la vérification était toujours active : deux commandes en parallèle, un état ambigu, et la confirmation pouvait s'appliquer à des données différentes de celles affichées. WebHID : pourquoi un site peut parler à votre appareil WebHID est une interface du navigateur permettant à un site web de communiquer directement avec un périphérique USB, après autorisation explicite de l'utilisateur. Sans ce mécanisme, l'usage d'un hardware wallet dans une application décentralisée serait moins fluide ; avec lui, un site se retrouve plus proche de l'appareil que beaucoup d'utilisateurs ne l'imaginent. L'attaque décrite suppose que vous ayez déjà accordé cet accès à un site manipulé ou compromis et que vous y initiiez une transaction. Elle ne fonctionne pas à distance contre un appareil déconnecté. Le périmètre est donc limité, mais concerne en pratique les utilisateurs réguliers de DEX, bridges ou interfaces de staking, qui accordent fréquemment ce type d'accès. Pourquoi les "approvals" illimités sont les plus dangereux Dans un échange de données de signature, le risque principal ne provient pas forcément d'un transfert ponctuel, mais de ce qui peut s'y substituer. Une "token approval" autorise un smart contract à dépenser ultérieurement vos jetons jusqu'à un certain montant, sans demander une confirmation pour chaque débit. De nombreuses applications demandent une autorisation illimitée pour des raisons de confort. Une approbation ne s'éteint pas d'elle-même : elle reste valable jusqu'à révocation explicite. Un transfert vous coûte le montant validé ; une approbation illimitée peut, dans le pire des cas, exposer la totalité du solde du jeton concerné, au moment choisi par le bénéficiaire. C'est pourquoi remplacer un petit transfert par une autorisation étendue constitue une cible privilégiée sur un chemin de signature. Mettre à jour l'application Ethereum en 1.22.2 via Ledger Live La version 1.22.2 ferme la voie d'attaque avec deux garde-fous : l'application refuse de démarrer une nouvelle session de signature tant qu'une vérification est en cours, et elle rejette une confirmation entrante si l'état interne ne correspond plus à ce qui a été affiché. La note de version apparaît dans l'aperçu des releases de l'application Ethereum chez Ledger ; elle mentionne uniquement des correctifs de sécurité, sans détailler la faille. La mise à jour est simple : connecter l'appareil, ouvrir le gestionnaire d'applications dans Ledger Live, puis mettre à jour l'application Ethereum. Les soldes ne changent pas : les clés proviennent de la phrase de récupération et ne sont pas stockées dans l'application. Supprimer puis réinstaller l'application n'entraîne pas non plus de perte de fonds. Comment vérifier la version installée Dans Ledger Live, le gestionnaire de l'appareil affiche la version de chaque application. Si l'application Ethereum indique 1.22.2 ou une version supérieure, le correctif est présent. Si elle indique 1.22.1 ou une version inférieure, elle reste vulnérable. Vérifier uniquement la version de Ledger Live ne suffit pas. Pourquoi une mise à jour du firmware ne met pas forcément à jour l'appli Ethereum Firmware, Ledger Live et applications "coin" sont maintenus et mis à jour séparément. Mettre à jour le firmware peut donner un faux sentiment de sécurité si l'application Ethereum reste ancienne. Cette séparation explique aussi pourquoi les discussions sur la sécurité des wallets comparent parfois des sujets différents : certaines failles concernent le firmware, d'autres une application remplaçable. Dans ce cas, la phrase de récupération n'a pas besoin d'être régénérée. En revanche, une seconde étape est recommandée : vérifier les anciennes autorisations (approvals) et les révoquer si nécessaire. Vérifier et révoquer les approvals : la seconde étape après la mise à jour Le correctif protège les signatures futures, mais ne modifie pas ce qui a déjà été accordé. Si vous avez utilisé des applications décentralisées ces derniers mois, il est pertinent d'inspecter les approvals toujours actives sur votre adresse. Les explorateurs de blocs et des interfaces spécialisées indiquent quels contrats ont le droit de dépenser quels jetons. Les autorisations accordées à des contrats que vous n'utilisez plus peuvent être révoquées une par une. Une révocation est une transaction standard et génère des frais réseau ; l'opération est souvent plus économique lorsque les frais sont faibles. Point souvent négligé : chaque révocation apparaît dans l'historique on-chain et coûte des frais. Pour ceux qui suivent proprement leurs mouvements, cela simplifie la prochaine déclaration fiscale ; les outils courants de fiscalité et de suivi de portefeuille importent généralement ces événements automatiquement. Désaccord sur la divulgation : Ledger contre TestMachine Deux récits s'opposent sur la chronologie, sans confirmation indépendante à ce stade. Le directeur technique de Ledger, Charles Guillemet, affirme que le laboratoire interne Ledger Donjon a découvert la faille et qu'un correctif a été livré environ deux semaines avant la publication. Il indique que TestMachine ne se serait manifestée auprès du programme de bug bounty qu'après coup, et décrit les déclarations de la société comme alarmistes. TestMachine répond que son système de test automatisé, Azimuth, a détecté la faiblesse lors d'une exécution sur un Ledger Flex et que les résultats ont été partagés avec Ledger. Selon la société, aucun correctif n'était disponible au moment de la publication. Les éléments vérifiables se situent entre les deux : l'entrée de changelog de la version 1.22.2 est datée du 12 août 2026, le tag signé dans le dépôt source du 13 août. La release n'est devenue visible comme publication qu'aux alentours du 24 août, en même temps que l'analyse de TestMachine. Un utilisateur cherchant à vérifier l'existence du correctif avant cette date ne pouvait pas le trouver via cette publication. Une reconstitution technique avec ces dates a été compilée par CryptoSlate. Des fonds ont-ils été volés ? Ce que l'on sait D'après les informations publiées par les deux parties, aucun cas confirmé d'exploitation n'a été documenté. Aucune perte n'est rapportée, et l'exfiltration des clés privées n'était de toute façon pas possible par ce vecteur. Cette absence de cas confirmés doit être nuancée : une signature obtenue ainsi ressemble on-chain à une signature volontaire. Un utilisateur touché ne s'en apercevrait probablement qu'au moment où des jetons sortiraient plus tard, et attribuerait l'incident à du phishing classique. On ne peut donc pas conclure avec certitude qu'aucune exploitation n'a eu lieu ; il s'agit d'une appréciation, pas d'un fait établi. Ce que l'épisode dit sur les hardware wallets et l'autodétention Cet épisode ne justifie pas de rejeter les portefeuilles matériels : l'attaque exigeait un accès déjà accordé, une application malveillante, la clé privée restait protégée et la faille est corrigée. La leçon opérationnelle est autre : un hardware wallet déplace la confiance de l'ordinateur vers un appareil doté d'un écran, mais cet ensemble repose sur plusieurs couches (firmware, applications, logiciel compagnon) mises à jour séparément. La sécurité n'est pas un état acquis à l'achat ; c'est une maintenance continue : garder les applications à jour, nettoyer régulièrement les approvals et, pour des montants importants, ajouter un niveau de confirmation supplémentaire. À retenir pour les utilisateurs Ledger 1) Vérifier la version et mettre à jour : connecter l'appareil, ouvrir le gestionnaire dans Ledger Live et contrôler l'application Ethereum. Toute version inférieure à 1.22.2 doit être mise à jour. Une mise à jour du firmware seule ne suffit pas. 2) Nettoyer les approvals en cours : vérifier quels contrats peuvent dépenser vos jetons et révoquer tout ce qui n'est plus nécessaire. 3) Documenter les opérations : révocations et réallocations génèrent des frais et s'inscrivent dans l'historique. Les noter au fil de l'eau facilite le suivi, notamment fiscal. (En date du 25 août 2026. Ce contenu ne constitue pas un conseil en investissement. Les prix et les structures de frais évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)