Ledger a corrigé le 12 août une faille de son application Ethereum. Le seul endroit où c'est écrit est son dépôt de code.

La promesse d'un portefeuille matériel tient à une chose : son écran montre ce qu'on s'apprête à signer, pour qu'on signe exactement ce qu'on lit. Tout le reste de la chaîne peut mentir, l'ordinateur, le navigateur, la page qu'on a sous les yeux ; l'écran de l'appareil, lui, est censé dire la vérité, et le doigt qui appuie la valide. Elle repose sur une condition qu'on ne prend jamais la peine d'énoncer, tant elle va de soi : que la chose affichée et la chose signée soient une seule et même chose, du premier coup d'œil jusqu'à l'appui, pendant les quelques secondes où le fil qui relie l'ordinateur à l'appareil reste ouvert.

Le 12 août, Ledger a refermé dans son application Ethereum le chemin par lequel cette chose pouvait être remplacée pendant qu'on la lisait.

Ce que le correctif referme, ligne par ligne

Le code de l'application Ethereum est public, et la comparaison entre les versions 1.22.1 et 1.22.2 se lit sans intermédiaire. Elle ne corrige aucun défaut d'affichage d'actif comparable à celui de 2021. Elle durcit la façon dont l'application sait ce qu'elle est en train de faire, et referme plusieurs chemins par lesquels l'ordinateur pouvait agir sur l'écran pendant une revue.

La modification la plus lisible tient en une ligne. Jusqu'à la 1.22.2, une commande ouvrant une nouvelle signature, reçue alors que l'appareil n'était pas au repos, réinitialisait le contexte en cours et poursuivait. Elle est désormais refusée. Trois gardes l'accompagnent : le mode de signature est figé à la première commande et un morceau suivant qui en changerait est rejeté ; la fonction qui valide une signature vérifie d'abord que l'application se trouve bien dans l'état qu'elle croit ; et toute revue en cours est fermée avant que ne soit libéré ce qu'elle affichait. Une douzaine d'autres durcissements suivent dans le même correctif, dont deux gardes qui empêchent l'ordinateur d'écraser un avertissement déjà affiché, ou de recouvrir une revue en cours par un nouvel écran.

S'y ajoute une correction de fond, plus parlante que les précédentes : l'inventaire des états de l'application passe de trois positions à sept. Vérification d'adresse, opération de confidentialité, préparation d'un message structuré, délégation de compte, chacune reçoit désormais son état propre. L'appareil ne savait pas assez finement ce qu'il faisait, et c'est de cette imprécision que naissait l'ouverture.

Deux mots, un tag, aucun bulletin

Le journal des modifications de l'application date la version 1.22.2 du 12 août 2026. Sous la rubrique des correctifs, il porte une ligne, deux mots : Security issues. Le lendemain à 09:54 UTC, le tag est poussé, suivi une demi-heure plus tard des cinq builds destinés au Stax, au Flex, au Nano X, au Nano S Plus et à l'Apex. La note de version du tag mentionne un fichier d'intégration continue. Le Nano S de première génération, resté en version 1.16.2, ne reçoit pas le correctif.

Ledger publie par ailleurs des bulletins de sécurité, numérotés, datés, détaillés. Il y en a vingt-deux. Au 24 août 2026, le dernier est daté du 4 juin. Aucun ne concerne le correctif du 12 août.

Ce n'est pas une capacité qui manque. En janvier 2021, un bulletin de la même série documentait un défaut d'affichage de cette même application Ethereum, nommait la version fautive, la version correctrice, le commit et le chercheur qui l'avait signalé. En mars 2025, la même équipe publiait ses travaux sur l'appareil d'un concurrent ; en septembre, ses découvertes sur les cartes d'un autre, sous divulgation coordonnée, chronologie des échanges à l'appui. Ledger sait annoncer. Il annonce quand il le décide.

Un délai pour corriger, aucun pour informer

La politique de divulgation que Ledger s'applique est publique, et elle est claire sur ce qu'elle attend du chercheur. En soumettant un rapport, celui-ci entre dans une forme de coopération où il laisse au fabricant l'occasion de diagnostiquer et de corriger la faille avant d'en divulguer les détails à des tiers ou au public. En retour, le texte annonce une prise de contact de l'équipe de sécurité, « en général sous vingt-quatre heures », et une politique de divulgation à quatre-vingt-dix jours, formulée comme un engagement de moyens.

Depuis le 13 avril 2026, ce même texte écarte les rapports générés entièrement ou principalement par des outils automatisés ou des systèmes d'intelligence artificielle sans analyse humaine. La justification est explicite : un rapport doit démontrer une compréhension réelle de la faille, sa cause, son impact, et une preuve d'exploitation écrite par celui qui la rapporte.

Le texte fixe donc un délai pour corriger. Il n'énonce aucun délai, aucune forme et aucun seuil pour informer les porteurs une fois la correction faite. Toute la retenue est demandée à celui qui trouve. Aucune obligation d'annonce ne pèse sur celui qui répare.

Deux comportements défendables, aucun arbitre

Le 22 août à 00:11 UTC, le cabinet TestMachine a publié un fil affirmant que « tout Ledger faisant tourner l'application Ethereum est vulnérable à une substitution de signature », un site malveillant auquel le porteur a déjà accordé l'accès à son appareil pouvant intercaler une commande pendant la revue et remplacer la transaction signée alors que l'écran continue d'afficher l'originale. La description du mécanisme correspond à ce que la 1.22.2 corrige. Le temps du verbe, lui, arrive dix jours après l'inscription du correctif au journal et neuf jours après sa publication.

Sur le seul plan de la correction, ce qui est documenté joue en faveur du fabricant. Le défaut est inscrit au journal le 12 août, tagué le lendemain, et le geste demandé au porteur n'a jamais dépassé une mise à jour d'application.

Les deux positions se défendent. Un porteur qui aurait voulu savoir, le 20 août, s'il devait mettre à jour d'urgence, n'avait à sa disposition que deux mots dans un fichier de dépôt et une note de version parlant d'outillage. Symétriquement, une alerte publiée au présent, sans date, sur un parc entier, déclenche une inquiétude qu'aucune information disponible ne permet de calibrer. Aucun texte écrit ne départage ces deux comportements, et c'est le vrai sujet de l'épisode.

La divulgation coordonnée est née d'une économie précise. Trouver coûtait cher, corriger prenait du temps, alors celui qui trouvait touchait une prime et acceptait de se taire. Les deux moitiés du contrat tenaient parce qu'elles vivaient à la même échelle de temps. Quand la découverte tombe à quelques heures de calcul, la première moitié se vide, et Ledger l'a acté en fermant sa porte aux rapports de machines. Rien n'a été écrit sur l'autre moitié. Le cas inverse a été documenté ici même il y a une semaine, sur Bitcoin, où un correctif prêt que personne ne peut activer laisse une dette ouverte. Ici le correctif est activé, et la dette reste chez celui qui n'est pas prévenu.

Sur quelle surface un porteur peut savoir

Le geste demandé se limite à une mise à jour de l'application Ethereum depuis Ledger Live. Rien de plus. Ni migration de fonds, ni régénération de clés, contrairement au cas d'une faille de génération de graine, où le risque ne disparaît pas mais se déplace vers le logiciel, le matériel et la chaîne de fabrication.

Ce que cet épisode déplace, c'est la surface auditable. Le bulletin de sécurité reste un choix éditorial du fabricant : il paraît quand celui-ci juge utile qu'il paraisse. Le journal des modifications, lui, est une contrainte d'ingénierie : il existe parce que le code en a besoin, pas parce qu'une direction en a décidé la publication. Sur ce correctif, c'est la contrainte qui a parlé et le choix qui s'est tu.

Ce n'est pas une bonne nouvelle, c'est un transfert de charge. On ne demande pas à un détenteur de portefeuille matériel de suivre un dépôt de code. Et sur cet épisode précis, la liste des bulletins, qui est faite pour prévenir, n'a rien dit ; le journal du dépôt, qui n'est pas fait pour ça, est le seul endroit où le fait existe.

Questions fréquentes

La faille est-elle encore ouverte ?
Non. Le correctif est inscrit au journal des modifications de l'application Ethereum le 12 août 2026 sous la version 1.22.2, et le tag correspondant a été publié le 13 août à 09:54 UTC. La date à laquelle la mise à jour a effectivement atteint les porteurs n'est publiée sur aucune surface publique, et n'est donc pas affirmée ici.

Est-ce le même problème que la faille d'affichage de 2021 ?
Non. Le bulletin de janvier 2021 portait sur des données de transaction non affichées par la version 1.6.0 de l'application, corrigée en 1.6.4. Le correctif d'août 2026 ne corrige aucun défaut d'affichage d'actif de ce type : il durcit les gardes d'état du flux de signature. Deux défauts distincts, plus de cinq ans d'écart.

Que doit faire un porteur de Ledger ?
Mettre à jour l'application Ethereum depuis le gestionnaire d'applications de Ledger Live. C'est la totalité du geste demandé. Aucune migration de fonds ni régénération de clés n'est requise, la faille ne portant pas sur la génération du secret mais sur le déroulé d'une signature.

Existe-t-il une obligation d'informer les porteurs après correction ?
La politique de bug bounty que Ledger publie fixe un délai de quatre-vingt-dix jours pour corriger et n'énonce aucun délai, aucune forme et aucun seuil pour informer. C'est la seule surface examinée ici : aucun régime réglementaire de signalement de vulnérabilités n'a été testé, et rien de plus général n'est affirmé.

Crypto Deep Research, 24 août 2026. Cet article est une analyse de sécurité et ne constitue ni un conseil en investissement ni une recommandation d'achat ou de vente.