Upbit a placé Zilliqa sous surveillance officielle de trading après qu’une faille critique dans l’application Zilliqa Ledger a permis de reconstruire des clés privées à partir de signatures de transactions déjà visibles on-chain.

La plateforme sud-coréenne — exploitée par Dunamu et plus grande plateforme de trading de cryptomonnaies en Corée par volume — n’a pas retiré ZIL de la cote. Le trading au comptant reste disponible pendant qu’Upbit examine l’incident, la réponse de Zilliqa et les protections en cours de développement pour les soldes affectés. Cette désignation donne à Zilliqa du temps pour traiter le problème de sécurité, mais elle ouvre également la voie à un retrait de la cote si Upbit estime que la vulnérabilité ou ses conséquences n’ont pas été correctement résolues.

Upbit maintient le trading de ZIL ouvert pendant l’examen

Selon l’avis officiel d’Upbit, ZIL est entré dans sa période d’examen sous surveillance le July 22. La fenêtre d’observation devrait se poursuivre jusqu’à la troisième semaine d’août, couvrant la période du August 17 au August 21.

Pendant cette période, le trading des paires ZIL/KRW et ZIL/BTC reste ouvert. Upbit peut lever la désignation de surveillance si les préoccupations de sécurité sont résolues, prolonger l’examen si davantage de temps est nécessaire, ou mettre fin au support de trading si elle détermine que les risques restent non résolus.

Les dépôts et retraits de ZIL avaient déjà été suspendus le July 20. Les nouveaux dépôts envoyés à Upbit alors que le service est bloqué peuvent ne pas être crédités et peuvent être retournés via le processus de récupération de la plateforme. Upbit a également indiqué que les retraits seront prioritaires lorsque les services de transaction commenceront à rouvrir. Les dépôts devraient rester indisponibles jusqu’à ce que la plateforme publie une annonce distincte.

Il en résulte un environnement de trading inhabituel. ZIL peut toujours être acheté et vendu au sein d’Upbit, mais les tokens ne peuvent actuellement pas entrer ou sortir librement de la plateforme. Le trading se poursuit donc alors que la voie de règlement sous-jacente reste restreinte.

ZIL s’échange à moins de 1% de son plus bas historique

La réaction du marché a rapproché ZIL de son plus bas historique. Sur le graphique journalier ZIL/USD sur OKX, le token s’échangeait près de $0.0024 à 13:15 UTC le July 22, en baisse d’environ 7% sur la journée, après avoir touché un plus bas intrajournalier de $0.00236. Ce plus bas se situait environ 1% au-dessus du plus bas historique de Zilliqa à $0.002339, selon CoinMarketCap.

Le plus fort volume de ventes quotidien des deux mois précédents a eu lieu le July 20, le jour où un vol depuis un portefeuille partenaire a été divulgué. L’indice de force relative quotidien était tombé à environ 28, sous le seuil traditionnel de survente de 30. Le prix se situait également bien en dessous des moyennes mobiles à 50 jours, 100 jours et 200 jours, qui continuaient toutes de s’incliner vers le bas.

La baisse reflète plus que le risque de perdre une cotation sur une plateforme d’échange. La faille sous-jacente affecte les clés privées de certains utilisateurs de Ledger et ne peut pas être annulée simplement en mettant à jour l’application de portefeuille.

Un bug de sept ans dans l’application Ledger a affaibli les signatures

L’incident de sécurité trouve son origine dans l’application Zilliqa utilisée sur les portefeuilles matériels Ledger. Il ne provient pas du matériel principal de Ledger et n’implique pas le mécanisme de consensus de Zilliqa.

Zilliqa a lancé son mainnet en 2019 comme l’une des premières blockchains publiques conçues autour du sharding pour le débit des transactions. Dans sa divulgation officielle de vulnérabilité, Zilliqa a déclaré que la faille affectait toutes les versions publiées du chemin de signature des transactions natives de l’application de 2019 à 2026.

Nonce-Generation Vulnerability in the Zilliqa Ledger App: A critical vulnerability has been identified in the Zilliqa Ledger application affecting the generation of Schnorr signatures for native (non-EVM) Zilliqa transactions. The vulnerability causes signatures to be generated… — Zilliqa (@zilliqa) July 22, 2026

Les transactions natives Zilliqa utilisent des signatures Schnorr. Chaque signature dépend d’un nombre secret temporaire, appelé nonce, qui doit être généré avec suffisamment d’aléa et ne doit jamais être prévisible.

L’application Zilliqa Ledger générait l’aléa requis, mais copiait la mauvaise section du résultat dans le processus de signature. Cette erreur laissait les 64 bits les plus significatifs de chaque nonce fixés à zéro, réduisant matériellement l’aléa qui protégeait chaque signature.

Une génération de nonce défectueuse a déjà entraîné des récupérations de clés privées très médiatisées dans d’autres systèmes cryptographiques. Le cas le plus connu concerne la PlayStation 3 de Sony, où l’entreprise avait réutilisé un nonce statique dans des signatures ECDSA, permettant à des hackers d’extraire la clé de signature et de déverrouiller la console. La vulnérabilité Zilliqa Ledger diffère dans son mécanisme, mais exploite le même principe : un aléa insuffisant du nonce expose la clé privée sous-jacente uniquement par des moyens mathématiques.

Une seule signature affaiblie ne divulgue qu’une partie des informations nécessaires pour reconstruire une clé privée. Des signatures répétées depuis le même compte en révèlent davantage. Zilliqa a indiqué qu’un attaquant pouvait récupérer la clé privée d’un compte affecté après environ cinq transactions natives ou plus en utilisant des signatures on-chain publiquement disponibles.

L’attaquant n’a pas besoin de posséder physiquement l’appareil Ledger, son PIN ni la phrase de récupération de l’utilisateur. Les données de signature nécessaires sont enregistrées de façon permanente sur la blockchain.

Portée de la vulnérabilité

L’incident ne constitue pas une compromission de tous les portefeuilles Zilliqa ni de la blockchain elle-même. Le risque est plus étroit, mais demeure critique pour les utilisateurs dont les transactions natives ont été signées via l’application Ledger affectée.

La vulnérabilité s’applique aux transactions Zilliqa natives, non-EVM, signées avec l’application Ledger touchée. La divulgation de Zilliqa s’est concentrée sur la génération de nonces par l’application pour les signatures Schnorr, plutôt que sur le matériel Ledger, le système de consensus de Zilliqa ou tous les types de portefeuilles du réseau. Les utilisateurs de portefeuilles logiciels, de portefeuilles hébergés par des plateformes d’échange ou d’appareils Ledger n’ayant signé que des transactions Zilliqa basées sur EVM ne sont pas affectés par cette faille spécifique.

L’exploitation a été détectée avant la divulgation publique

La chronologie a évolué rapidement. Une activité on-chain suspecte a été observée le July 19, un vol a été signalé le July 20, la cause racine a été isolée le July 21, et la désignation de surveillance d’Upbit a suivi le July 22.

Le rapport du July 20 concernait des ZIL volés depuis un cold wallet exploité par un partenaire d’échange, que Zilliqa n’a pas nommé. Le projet a contacté des plateformes d’échange et demandé des restrictions temporaires sur les dépôts et retraits natifs de ZIL pendant l’enquête sur l’origine de l’incident.

Zilliqa a crédité KuCoin pour son aide dans l’identification de la défaillance, la reconstruction des clés privées affectées à partir de signatures publiques et la confirmation qu’une exploitation était en cours. Les transactions natives Zilliqa ont ensuite été suspendues afin d’empêcher le drainage de fonds supplémentaires pendant l’élaboration d’une procédure de récupération.

Une version corrigée de l’application Ledger a également été préparée en coordination avec Ledger. Le correctif rétablit l’aléa complet requis lors de la production de nouvelles signatures.

Pourquoi il a été demandé aux utilisateurs de ne pas déplacer les fonds de manière indépendante

La réponse habituelle à un portefeuille de cryptomonnaies compromis consiste à créer une nouvelle adresse et à déplacer immédiatement les actifs restants. Zilliqa a averti que cette réponse pourrait être inefficace ou dangereuse dans ce cas.

Si un attaquant a déjà reconstruit la clé privée, le détenteur légitime et l’attaquant peuvent tous deux signer des transactions valides depuis la même adresse. Lorsque les transferts natifs reprendront, un attaquant pourrait surveiller le compte et tenter de soumettre une transaction concurrente avant que le transfert du propriétaire ne soit confirmé.

Une évacuation standard du portefeuille pourrait donc devenir une course entre deux parties contrôlant la même clé. Elle pourrait également alerter un attaquant sur un compte contenant encore des actifs.

"Users who have signed native Zilliqa transactions with a Ledger device should await official guidance before taking any action."

Divulgation officielle de sécurité de Zilliqa

Les clés privées affectées devront à terme être retirées, mais Zilliqa n’a pas conseillé aux utilisateurs d’effectuer ce processus de manière indépendante. Le projet finalise un plan coordonné destiné à protéger les soldes affectés pendant que les transactions natives restent suspendues.

Les utilisateurs doivent éviter de suivre des instructions de migration de portefeuille non vérifiées, de saisir des phrases de récupération sur de nouveaux sites web ou de répondre à des messages directs proposant de l’aide. Le processus de remédiation doit être suivi uniquement via les communications officielles de Zilliqa et de Ledger.

Le correctif ne répare pas les clés précédemment exposées

Le caractère permanent de l’historique des transactions blockchain constitue le défi central. L’application corrigée empêche seulement la création de nouvelles signatures affaiblies. Toute signature vulnérable déjà publiée reste publiquement disponible pour toujours.

Un attaquant peut effectuer le calcul de récupération de clé privée à tout moment en utilisant d’anciennes signatures. Mettre à jour l’application, changer le PIN du Ledger ou réinstaller le logiciel de portefeuille ne modifie pas la clé privée qui contrôle l’adresse affectée.

Réinitialiser un portefeuille matériel avec la même phrase de récupération recréerait également les mêmes clés sous-jacentes. Une clé véritablement retirée devrait à terme être remplacée par une nouvelle clé générée qui ne dérive pas du matériel de récupération compromis.

Même cette étape technique ne résout pas le problème immédiat de transfert tant qu’un attaquant peut contrôler l’ancienne adresse. L’élément manquant est un mécanisme coordonné permettant de déplacer ou de protéger les soldes sans exposer les utilisateurs à une course de transactions lorsque le réseau reprendra.

La décision d’Upbit dépend du plan de remédiation

La décision finale d’Upbit dépendra probablement de plus que la publication d’une application Ledger corrigée. La plateforme doit également évaluer la manière dont Zilliqa protège les soldes associés à des clés qui peuvent déjà être compromises.

Une réponse complète devrait établir la population de comptes affectés, fournir un processus de récupération sûr, empêcher des transferts non autorisés supplémentaires et expliquer comment les services de transactions natives peuvent reprendre sans créer une nouvelle opportunité pour les attaquants.

La fenêtre d’examen d’août crée une échéance claire pour Zilliqa. La réparation du code de signature traite le défaut technique initial, mais le rétablissement de la confiance de la plateforme exige une solution crédible pour les clés et les soldes qui ont été exposés avant l’existence du correctif.

Tant que ce plan n’est pas publié, ZIL reste négociable sur Upbit mais soumis à des restrictions opérationnelles, tandis qu’il est demandé aux utilisateurs Ledger affectés d’attendre plutôt que de tenter un transfert indépendant.

Revue des sources : basée sur l’avis officiel d’Upbit, les divulgations de sécurité de Zilliqa sur X, les données de marché ZIL/USD de TradingView (OKX) et les données de plus bas historique de CoinMarketCap, vérifiées le July 22, 2026.