A Different Transaction Could Be Signed on Ledger: Update Apps via Ledger Live

A Ledger user could sign a different transaction while seeing another on the screen; apps must be updated via Ledger Live for protection.

According to a report by Wu Blockchain, the OneKey Anzen team reproduced a transaction substitution attack in a lab environment on Ledger Ethereum App version 1.22.1. In this scenario, while the user sees and approves transaction A, the device can sign transaction B, which is not shown on the screen. Ledger users need to update not only the device firmware but also the relevant apps via Ledger Live.

OneKey founder Yishi stated that the issue stems from a timing error known as a race condition between the transaction screen and the section where data waiting to be signed is held. When two transactions are processed simultaneously, an attacker can change the content of the pending transaction while the user is reviewing the legitimate one. Thus, the information shown on the screen and the information signed by the device can diverge.

Ledger Fixed the Vulnerability at the App and SDK Layer

In security bulletin LSB 023, Ledger announced that some apps could continue to receive new APDU commands while the approval screen was open. APDU refers to the commands that provide data communication between the device and the app. This situation can lead to differences between the transaction parameters shown on the screen and the signed parameters.

The company stated that the issue did not stem from the device operating system or firmware, but rather from the data input-output operations of the Ledger Secure SDK. The fix was implemented through app controls and SDK changes. Version 26.6.1 of the Ledger Secure SDK was released on August 21, and it was emphasized that a firmware update alone is not sufficient.

While the OneKey statement identified the fix version as 1.22.3, community notes stated that Ledger resolved the vulnerability with Ethereum App 1.22.2. Ledger also reported that there is no evidence to date that the vulnerability has been exploited.