What Ledger disclosed
Ledger published Security Bulletin 024 on August 27. Its Ethereum app Generic Transaction Parser read an attacker-controlled array length as a 16-bit value but stored the review countdown in an 8-bit field. An array of 257 elements therefore became 1: the device displayed only the final operation while its EIP-712 signature still authorized the complete batch.
Ledger classifies the report as High and says Ethereum app versions 1.19.0 through 1.22.2 are affected. Version 1.22.3 rejects counts that cannot fit before the narrowing assignment. Ledger says there is no known exploitation; its end-to-end validation used one owner on a private network fork, with no production frontend compromise, public-network transaction, or real funds moved.
The trusted display failed at a representation boundary
This was not a cryptographic failure. The signature correctly covered the transaction bytes, and the receiving contract correctly verified it. The broken invariant sat between representation and authorization: the signer summarized fewer actions than the signature approved. Type narrowing turned a valid encoded count into a different review count without rejecting the transaction.
Wallet and contract teams should treat transaction rendering as security-critical parsing, not interface polish. Lengths, indexes, enum values, decimal conversions, nested offsets, and unknown fields need checked conversions and fail-closed behavior. Tests should compare the exact semantic object displayed to the exact object hashed, including boundary values such as 255, 256, and 257 and generated adversarial structures—not only normal transactions.
Threshold signatures are not independent reviews by default
Ledger notes that the flaw does not reduce a multisig threshold: an attacker still needs the required signatures over the same hash. But if every owner uses the same affected app and descriptor, every trusted display can repeat the same parsing error. Multiple confirmations then provide key independence without verification-path independence.
High-value operations should diversify how intent is checked. One signer can use a separately implemented decoder; another can verify a human-readable transaction manifest against simulation output; policy infrastructure can enforce batch-size, destination, selector, value, and aggregate-limit rules before signatures are requested. For exceptional batches, an out-of-band approval record should identify the transaction hash and expected operation count. More devices running identical code are redundancy, not defense in depth.
Immediate operational response
Operators using Ledger for Ethereum signing should verify that every signer runs app version 1.22.3 or later, rather than assuming a wallet-management workflow completed the update. They should inventory clear-signing descriptors and batch-capable contract entry points, flag arrays near parser limits, and temporarily require an independent decode or simulation for unusually large batches.
The bulletin says exploitation requires a compromised host, a descriptor that iterates an attacker-controlled array above 255 elements, and a contract that accepts that shape. Those constraints make exploitation narrow, but they should guide detection: review historical signing requests for oversized arrays and unexpected batch composition, while keeping the absence of known exploitation separate from evidence that a specific environment was unaffected.
Ineeza’s view
Financial authorization systems need semantic integrity from transaction construction through display, policy evaluation, signature, and execution. The durable lesson is to make those stages mutually checkable. A threshold controls how many keys must consent; only independent parsing, simulation, and policy controls help ensure those keys consented to what operators believed they saw.