Ledger Security Bulletin 024
Clear-signing bypass via array-count truncation in the Ethereum app
27 August 2026: The device reviewed a single operation out of a list of more than 255, while its signature authorised all of them.
Summary
A vulnerability was identified in the Ethereum app for Ledger devices where the Generic Transaction Parser stored an attacker-controlled 16-bit array element count in an 8-bit countdown field. For an array of 257 elements the count truncated to 1, so the device reviewed only the final element while its signature still authorised the complete transaction.
The vulnerability was reported through the Ledger bug bounty programme and is fixed in Ethereum app version 1.22.3.
Ledger has additionally hardened a number of lower-severity clear-signing and review paths in the same release. Those changes are listed under Additional hardening. None of them is known to have been exploited, and none is individually of the same severity as the issue described here.
Description
Some transactions contain a list of operations rather than a single one. When clear signing is available for such a transaction, the app walks through the list and shows each entry to the user before the transaction is signed.
The app counted the entries in that list using a 16-bit value, but stored the count in a field only 8 bits wide. Any count above 255 therefore wrapped around. A list of 257 entries was recorded as 1, and the app reviewed a single entry instead of all of them.
The signature still covered the transaction in full. A transaction could therefore be crafted so that the device displayed one harmless operation while the resulting signature authorised every other operation in the list as well.
Impact
Exploitation requires a compromised host and a clear-signing descriptor that iterates an attacker-controlled array of more than 255 elements. It does not require blind signing, a non-default setting, or physical access to the device.
In practice the flaw is difficult to exploit, because a list of more than 255 elements is an unusual shape for calldata. Many contracts reject it outright: batch entry points commonly bound the length of the array they accept, and a batch of that size is often impractical to execute in any case. A usable target must therefore accept an array above that threshold, iterate it, and be covered by a clear-signing descriptor that walks it, which is a narrow combination.
Where those conditions are met, the primary threat is a compromised multisig frontend. Malicious code inside an authorised transaction interface controls what is sent to each signer’s device and collects the signatures returned. Affected devices show only the benign final action, so the independent verification boundary the trusted display is meant to provide does not hold.
Where a threshold of signatures is required, the attacker still needs that full threshold over the same transaction hash, and the flaw does not lower it. What it does is cause several apparently independent device confirmations to repeat the same parsing failure. The receiving contract can verify the signatures it is given, but cannot determine whether the signing devices described the hash correctly to their users.
The authorisation and execution boundary was validated end to end for a single owner. An affected build produced an EIP-712 signature covering a batch of 257 operations after displaying only one of them, the receiving contract accepted that signature as valid for the batch, and the batch was executed on a private fork of the network. The resulting receipt contained 256 operations that the device had never displayed.
It should be noted that no production frontend was compromised, no multi-owner signing ceremony was reproduced, no transaction was broadcast to a public network, and no real funds moved.
Affected releases
Ethereum app versions 1.19.0 through 1.22.2, being the releases in which the nested-calldata descriptor capability required by the proof of concept is present.
Remediation
The fix rejects an array element count that cannot be represented in the countdown field, before the narrowing assignment takes place.
Users should install Ethereum app 1.22.3 or later and verify the application version on the signer.
Additional hardening in the same release
Alongside the correction above, Ethereum app 1.22.3 hardens a set of lower-severity review and clear-signing paths found during Ledger’s own continuous security review of the application. Each was corrected before any evidence of exploitation, and each requires materially stronger preconditions than the vulnerability described above: typically a Ledger-signed descriptor of an unusual shape, a non-default device setting, or an already-installed malicious companion application.
Credit
The vulnerability described in this bulletin was reported by Felipe A. Manzano, Bitfinding, through the Ledger Devices Bug Bounty programme. Ledger thanks Bitfinding for the report, for the quality of the accompanying proof of concept.
A variant of the same vulnerability was independently reported by Florian Pradines, independent security researcher, through the same programme.
Ledger thanks the security researchers who continue to submit findings against its applications through the bug bounty programme. The hardening changes listed above were identified by Ledger’s internal continuous security review of the Ethereum app.
Timeline
| Date | Action |
|---|---|
| 28 March 2026 | An encrypted report and proof of concept are submitted through the bug bounty programme. |
| 31 March 2026 | Ledger acknowledges receipt. |
| 23 April 2026 | Ledger validates exploitability, classifies the report as High, and begins remediation coordination. |
| 30 April 2026 | A correction is developed. |
| 4 May 2026 | Both parties agree an early-September public disclosure window. |
| 5 May 2026 | The correction is merged. |
| 13 August 2026 | Ethereum app 1.22.2 is tagged without the correction. |
| 23 August 2026 | The reporter notes that the correction is absent from 1.22.2 and asks Ledger to identify the first installable fixed release. |
| 25 August 2026 | Ledger publishes Ethereum app 1.22.3 with the backported correction for all five targets. The reporter confirms the fixed-version regression result. |
| 27 August 2026 | Security bulletin published. |