Une faille de sept ans dans une application Ledger. Comment savoir si votre clé est concernée, et quoi faire.

La question se pose à tout porteur de portefeuille physique depuis le 22 juillet, et elle mérite une réponse nette plutôt qu'un frisson. Un appareil Ledger n'exécute pas un seul logiciel : il en charge un par blockchain, une application Bitcoin, une application Ethereum, une application Zilliqa. Celle de Zilliqa produisait des signatures défectueuses depuis 2019. Les autres ne sont pas en cause, et le matériel non plus.

Le concernement se règle donc par un test précis, pas par une intuition. Voici lequel, puis la marche à suivre.

Êtes-vous concerné ? Le test en trente secondes

Trois conditions, cumulatives. La première : avoir installé l'application Zilliqa sur l'appareil, depuis la section My Ledger de Ledger Live. C'est elle qui signe, et sans elle il n'y a pas d'exposition, point final. Attention au piège de mémoire : Ledger Live ne gère pas les comptes Zilliqa, la manipulation passe ensuite par un portefeuille dédié, ZilPay ou Zillet, qui se connectent l'un comme l'autre à l'appareil. Avoir utilisé l'un plutôt que l'autre ne change rien au périmètre.

La deuxième : avoir effectivement envoyé des ZIL par cette voie, en transactions natives non-EVM. La troisième : en avoir signé environ cinq ou plus depuis 2019, seuil à partir duquel la clé privée devient reconstituable à partir des seules données publiques de la blockchain.

Qui n'est pas concerné, et cela couvre l'immense majorité des porteurs : tous ceux dont l'appareil ne contient pas cette application. Le bitcoin, l'ether et le reste du catalogue passent par des logiciels distincts, écrits séparément, qui ne partagent pas ce défaut. L'usage de Zilliqa en mode compatible EVM n'est pas exposé non plus, pas plus que les kits de développement officiels zilliqa-js, gozilliqa-sdk et pyzil.

Un piège à éviter en chemin : ne pas trancher au format de l'adresse. Une adresse Zilliqa native s'écrit en zil1… mais aussi en base16 0x…, si bien que le préfixe ne prouve rien. Le seul discriminant fiable est le chemin emprunté pour signer.

Ce qu'il faut faire, et surtout ne pas faire

Pour qui coche les trois cases, la consigne du projet surprend au premier abord : les clés touchées doivent être abandonnées, pas transférées. La nuance décide de tout. Un attaquant qui a déjà reconstitué la clé observe la même blockchain que tout le monde ; il devance le mouvement de celui qui tente de déplacer ses fonds. Vider l'adresse en urgence revient à courir une course déjà perdue.

L'issue passe par une migration coordonnée, que l'équipe indique préparer avec Ledger, transactions natives gelées le temps de la mettre en place. Autrement dit, l'action utile ici consiste à attendre les instructions officielles plutôt qu'à improviser.

Reste la partie que personne n'aime rappeler et qui fait pourtant les vraies pertes. Une divulgation publique de cette nature attire mécaniquement les faux supports : messages privés compatissants, sites de migration d'apparence officielle, formulaires de vérification. Aucune procédure légitime ne demande une phrase de récupération, jamais, sur aucun site. Les instructions de migration ne se suivent que sur les canaux officiels du projet et de Ledger. Le second risque, dans ce genre d'affaire, arrive toujours après le premier.

Si vos ZIL sont sur une plateforme, la question change

Les jetons détenus sur un exchange ne posent aucun problème de clé, puisque le porteur n'en détient aucune. Le problème devient celui de l'accès, et il s'est refermé plus tôt qu'on ne le croit.

Le 20 juillet à 19h00 heure de Séoul, Upbit suspend les dépôts et retraits de ZIL. Deux jours avant la divulgation publique, sur la foi d'indices d'incident survenu chez une plateforme d'échange qu'elle ne nomme pas. Le 22 juillet à la même heure, elle désigne ZIL en valeur sous surveillance sur les marchés ZIL/KRW et ZIL/BTC. Bithumb fait de même dans la journée.

Le motif retenu par l'avis mérite d'être lu dans le texte : la loi coréenne de protection des utilisateurs d'actifs virtuels vise, dans son décret d'application, l'incident de sécurité dont la cause n'est pas élucidée ou n'est pas guérie. Les conséquences pratiques sont écrites noir sur blanc. Plus aucun dépôt n'est crédité et tout dépôt entrant est retourné, les retraits rouvriront en premier lorsqu'ils rouvriront, et l'examen court jusqu'à la semaine du 17 au 21 août. À son terme, la cotation peut être maintenue, prolongée sous surveillance, ou arrêtée. Le marché a pris acte : ZIL cotait 0,002438 $ le 23 juillet pour 47,6 millions de dollars de capitalisation, après un plus bas historique inscrit la veille à 0,0023443 $.

Deux inconnues demeurent, et elles comptent pour juger l'ampleur réelle : ni le montant dérobé ni le nombre d'adresses touchées n'ont été publiés à ce jour.

Pourquoi un correctif ne suffit pas ici

Reste à comprendre pourquoi la consigne est d'abandonner une clé plutôt que de la vider, et pourquoi un régulateur exige une guérison. La réponse tient à la nature de cette faille, qui la distingue de presque toutes les autres.

Un pont piraté peut être remboursé. Un contrat vulnérable peut être migré. Un serveur compromis peut être reconstruit. Une signature défectueuse, elle, est publiée sur un registre public, définitivement, et se rejouera dans six mois exactement comme aujourd'hui. Chaque signature émise depuis 2019 laissait fuiter un morceau de la clé, et ces morceaux sont toujours là, lisibles par quiconque. La version corrigée de l'application protégera les signatures futures. Elle ne peut rien contre les sept années déjà écrites. C'est aussi ce qui rend la condition de sortie du dispositif coréen si difficile à remplir : la cause est parfaitement élucidée, c'est la guérison qui n'existe pas.

La leçon dépasse largement ZIL. La surface de risque d'un portefeuille physique n'est pas le boîtier, c'est l'application de signature propre à chaque chaîne. Ces applications sont écrites par les équipes des projets, puis soumises à un audit réalisé par un partenaire agréé selon les spécifications de Ledger, avant publication au catalogue. Une fois publiées, elles vivent leur vie. Sur Ostium, le composant que le périmètre d'audit laissait de côté était l'infrastructure d'oracle, et c'est par là que la perte est arrivée. Ici, c'était la génération d'un nombre aléatoire dans une application discrète du catalogue. La bonne question, pour chaque chaîne que l'on signe, n'est pas de savoir si l'appareil est sûr : c'est de savoir qui a écrit l'application qui signe, et quand elle a été regardée pour la dernière fois.

Questions fréquentes

J'ai un Ledger avec du bitcoin et de l'ethereum, suis-je concerné ?
Non. Chaque chaîne passe par une application distincte installée sur l'appareil, et la faille ne touche que l'application Zilliqa. Sans cette application et sans transaction ZIL native signée avec elle, il n'y a aucune exposition. Le matériel et le système de Ledger ne sont pas en cause.

Comment savoir si j'ai signé des transactions ZIL natives ?
La voie native suppose d'avoir installé l'application Zilliqa depuis la section My Ledger de Ledger Live, puis d'avoir connecté l'appareil à un portefeuille Zilliqa dédié, ZilPay ou Zillet, pour envoyer des ZIL. L'usage de Zilliqa en mode EVM et les kits officiels zilliqa-js, gozilliqa-sdk et pyzil ne sont pas concernés. Le format de l'adresse ne permet pas de trancher, puisqu'une adresse Zilliqa native existe aussi dans son ancien format base16 en 0x… : c'est le chemin utilisé qui compte.

Je pense être concerné, que faire maintenant ?
Ne pas transférer les fonds : la consigne du projet est d'abandonner les clés touchées, parce qu'un attaquant qui détient déjà la clé peut devancer tout mouvement. Les transactions natives sont gelées et un plan de migration coordonné avec Ledger est annoncé. Aucune instruction de migration ne doit être suivie hors des canaux officiels, et une phrase de récupération ne se saisit jamais sur un site tiers.

Mes ZIL sont sur une plateforme d'échange, que risquent-ils ?
La clé n'est pas en cause, l'accès l'est. Chez Upbit, dépôts et retraits sont suspendus depuis le 20 juillet 2026 et tout dépôt entrant est retourné. La désignation en valeur sous surveillance du 22 juillet ouvre un examen jusqu'à la semaine du 17 au 21 août, qui peut se solder par une levée, une prolongation ou un arrêt de la cotation. Bithumb a pris la même mesure.