News

Ledger Zilliqa App Vulnerability 26.07.2026

Focused Security Analysis: Nonce Error in Zilliqa Ledger App Allows Private Key Recovery from ~5 Native Signatures - and What This Means for Hardware Wallet Users in the Region.

Toms Ābeltiņš

26 July 20266 min read

Between 19-22 July, it was revealed that the Zilliqa Ledger app had been generating weak Schnorr nonces for years, allowing private keys to be recovered from ~5 native signatures in seconds. Why the hardware wallet didn't protect, how it affects the region, how exchanges reacted (Upbit: ZIL cautionary asset), and what remains on the watchlist.

Sunday, 26 July 2026. This is a focused security publication for our segment, not a daily news review. The reason must be stated honestly: in the last 24-48 hours, no new, primary news has emerged in our segment - crypto exchanges and CASP, hardware wallets, crypto cards, and tax tools for the Baltics and Nordics. However, within the week, there has been one significant event, previously uncovered by us, directly in the second category of our segment - hardware wallets: a critical vulnerability in the Zilliqa Ledger app that allows a user's private key to be recovered. The core of the event unfolded between 19-22 July, so we are treating it as this week's main security topic with an in-depth explanation, regional context, and a watchlist, rather than as 'yesterday's' news.

What Happened

On 19 July, activity consistent with an active exploit was observed on-chain; on 21 July, the Zilliqa team confirmed the cause and paused native (non-EVM) transactions on the network, and on 22 July, they published a formal announcement. The problem is specific: it affects the official Zilliqa Ledger app and the way it generates Schnorr signatures for native Zilliqa transactions on the secp256k1 curve.

Technically, the error lies in nonce (a single random value) generation. The app created 40 bytes of randomness and reduced the result modulo the curve order, but then copied an incorrect 32-byte range into the nonce buffer - retaining eight zero-padded bytes and discarding eight bytes of actual entropy. As a result, the upper 64 bits of each nonce were fixed to zero (i.e., k < 2¹⁹²). Such predictability is fatal: an attacker with approximately five or more native signatures from the same key can recover the private key using standard lattice reduction methods - in seconds, on everyday hardware.

The vulnerability has existed since 2019 and only affects native Zilliqa transactions signed with Ledger. It does not affect EVM-compatible transactions, nor the zilliqa-js, gozilliqa-sdk, and pyzil libraries. The exchange KuCoin helped discover the problem by tracing it.

Why the Hardware Wallet Didn't Protect Here

This case is important for users in our region precisely because it undermines the simplistic assumption that 'if I use a hardware wallet, I am safe'. The vulnerability is not in the Ledger secure element or the device's operating system - it is in the specific cryptocurrency signing app running on the device. The hardware wallet correctly kept the key isolated, but the signatures it produced themselves leaked enough information to recover the key.

The practical lesson is that the security of a hardware wallet is only as strong as the signing code for each coin. Ledger, Trezor, BitBox, Coldcard, and Tangem all rely on separate apps or firmware modules for specific networks, and an error in cryptographic implementation - especially in nonce generation - can completely bypass the device's physical isolation. Nonce reuse and weak nonce problems are not new; they have historically compromised both software and hardware signers. What is new here is a specific, datable instance in a real, widely used ecosystem.

Impact on Regional Users

The direct impact in the Baltics and Nordics is likely limited: the proportion of native Zilliqa assets in the portfolios of private users in the region is small compared to Bitcoin, Ethereum, or major stablecoins. However, Ledger is one of the most common hardware wallets for private self-custody in the region, and after the end of the MiCA transition period on 1 July, some users have moved from exchanges directly to self-custody. Therefore, the principal lesson applies broadly, even if the specific asset does not.

For those rare regional users who have indeed signed native Zilliqa transactions with Ledger, the situation is serious: if there are approximately five or more such signatures from one key on-chain, the key is considered compromised. The patched app does not restore security to keys that have already been exposed by signatures already recorded on-chain - a later fix prevents future signatures but does not undo past leakage.

Exchange Reaction

Upbit reacted strongly, designating ZIL as a 'cautionary asset' in both KRW and BTC trading pairs, suspending deposits and withdrawals, and warning that trading support could be terminated altogether if the problem was not quickly resolved. KuCoin, as mentioned, was involved in tracing the cause. Neither Zilliqa nor the exchanges have publicly disclosed how many private keys were actually compromised or what the total loss in dollars is. Direct involvement of regional exchanges has not been documented so far, but regional users holding ZIL on external platforms should check the respective platform's announcements regarding deposit/withdrawal status.

Watchlist

Several questions remain open and are worth considering in the coming days. Firstly, the release date of the patched Ledger app: Zilliqa indicated that a corrected version with full-width nonce generation has been prepared in collaboration with Ledger, but release details will be announced separately. Secondly, the resumption of native transactions on the Zilliqa network and the full recovery procedure, which has not yet been published at the time of writing. Thirdly, whether other exchanges follow Upbit's example with ZIL restrictions. Fourthly, and on a broader scale - whether Ledger or other hardware wallet manufacturers implement additional checks for third-party coin app signing code, as this case highlights precisely this link in the chain of trust.

What Regional Users Should Do

For users who have signed native Zilliqa transactions with Ledger, Zilliqa's official recommendation is to await team instructions before taking any action, as incorrect movement of funds in a compromised environment can accelerate their loss. For the wider audience not using Zilliqa, the practical action is conceptual: keep hardware wallet firmware and coin apps updated, follow official security announcements from manufacturers and networks, and do not consider a hardware wallet an absolute guarantee - it protects the key from exfiltration but does not protect against errors in signing implementation. Diversification between wallet models and attention to official CVEs and security announcements remains sound practice.

Norriwire Briefing