Que corrige exactement Ledger ?
Le Donjon, l'équipe sécurité de Ledger, a publié deux bulletins le 27 août 2026. Le premier décrit une classe de vulnérabilité dans le Ledger Secure SDK, le code partagé que chaque application embarque dans son propre binaire. Le second vise l'application Ethereum, qui pouvait n'afficher qu'une seule opération d'une liste en comptant plus de 255. Le résultat est le même dans les deux cas. L'appareil décrit une opération à l'écran, la signature produite en autorise une autre. C'est la garantie d'affichage de confiance qui tombe, celle qui justifie l'existence d'un portefeuille matériel comme le Ledger.
Comment une commande peut-elle en écraser une autre ?
Une application Ledger traite une commande APDU, rend la main à l'interface et renvoie IO_ASYNCH_REPLY sans répondre à l'hôte. La réponse part plus tard, depuis le callback d'approbation ou de rejet. Pendant cet intervalle, l'écran de revue reste affiché et les paramètres qui seront signés, chemin de dérivation, empreintes, montants, adresses de destination, subsistent dans des structures globales. Le code de réception du SDK n'empêchait pas l'hôte d'envoyer une commande supplémentaire durant cette attente. Chaque application devait donc rejeter elle-même les commandes intercalées. Celles qui vérifiaient leur état à chaque point d'entrée asynchrone se comportaient correctement. Un seul point d'entrée sans contrôle suffisait à ouvrir la fenêtre. Deux propriétés rendaient l'exploitation praticable et non théorique. Plusieurs commandes acceptent leur charge utile par morceaux, si bien qu'un premier morceau pouvait écraser un champ de tête avant que l'attaquant s'arrête et retienne la suite. La commande interrompue ne renvoyait alors aucune erreur et ne fermait aucun écran. L'utilisateur ne voyait rien, la revue d'origine restait affichée, et sa confirmation portait sur autre chose. Ledger classe le défaut en CWE-362, une condition entre le moment du contrôle et celui de l'usage. L'attaque suppose un adversaire maître de l'échange APDU : une application de portefeuille compromise, une page hostile détenant une connexion WebHID ou WebUSB, ou un logiciel malveillant sur l'ordinateur. Les mécanismes par lesquels un script s'exécute dans le navigateur de la victime ou par lesquels un attaquant s'intercale dans une transaction suffisent à réunir cette condition. Ledger indique n'avoir aucune preuve que le défaut ait été exploité contre des utilisateurs, et précise que la substitution n'est détectable ni sur l'appareil ni par la personne qui approuve.
Qui est concerné et par quelle mise à jour ?
Le défaut est une régression introduite au cours d'août 2025. Les versions antérieures ne permettaient pas d'intercaler des commandes. Sont concernées les applications compilées avec un SDK allant de ce point jusqu'à v26.6.0 inclus. Le système d'exploitation de l'appareil et son micrologiciel ne sont pas touchés, ce qui explique que la correction arrive par une mise à jour d'application.
| Date | Étape |
|---|---|
| 11 août 2026 | SDK v26.6.0, dernière version exposée |
| 13 août 2026 | première application durcie, Ethereum 1.22.2 |
| 21 août 2026 | SDK v26.6.1, commandes intercalées rejetées |
| 25 août 2026 | Ethereum 1.22.3, correction du compteur |
| 27 août 2026 | publication des deux bulletins |
Ledger a revu ses applications maison et les a recompilées. Pour les applications tierces, la correction dépend des développeurs, invités à contrôler leurs gestionnaires de commandes et à recompiler contre v26.6.1 ou une version ultérieure.
Que se passait-il avec les listes de 257 opérations ?
Le second bulletin porte sur le Generic Transaction Parser de l'application Ethereum. Le nombre d'éléments d'un tableau était compté sur 16 bits puis rangé dans un champ de 8 bits. Toute valeur au-delà de 255 repartait de zéro. Une liste de 257 entrées était enregistrée comme 1, l'appareil n'affichait qu'une opération et la signature couvrait la transaction entière. Les versions 1.19.0 à 1.22.2 sont concernées. La démonstration a produit une signature EIP-712 couvrant un lot de 257 opérations après en avoir affiché une seule, le contrat destinataire l'a acceptée et le lot a été exécuté sur un fork privé du réseau. Le reçu contenait 256 opérations jamais montrées à l'appareil. Aucune interface de production n'a été compromise et aucun fonds n'a bougé. La cible principale serait une interface multisignature compromise, où plusieurs appareils répètent la même erreur d'analyse. Le rapport vient de Felipe A. Manzano, de Bitfinding, transmis le 28 mars 2026 via le programme de bug bounty de Ledger. Une variante a été signalée indépendamment par le chercheur Florian Pradines.
Pourquoi OneKey et Ledger s'opposent-ils ?
Selon Decrypt et Protos, Yishi Wang, fondateur de OneKey, a annoncé le 27 août sur X que l'équipe Anzen de son entreprise avait reproduit en laboratoire une attaque par remplacement de transaction contre la version 1.22.1 de l'application Ethereum. Il décrit une condition de course entre la logique d'affichage et le tampon de transaction. Charles Guillemet, directeur technique de Ledger, a rejeté le terme employé, estimant que reproduire un défaut déjà corrigé ne constitue pas un piratage de Ledger. Il rappelle que la correction a été livrée dans l'application Ethereum 1.22.2, publiée le 13 août. Ledger recommande d'installer l'application Ethereum en version 1.22.3 ou ultérieure et de vérifier le numéro de version affiché sur l'appareil.
