How the display and signature could diverge
A Ledger device receives APDU commands from the connected computer. An application parses a request, presents the address, amount and other fields on the trusted display, then waits for the user to approve or reject it. Because the reply is asynchronous, the application keeps part of the operation state in memory while the review screen remains open.
Ledger Security Bulletin 023 describes a gap during that wait. The Secure SDK input path could begin handling another APDU command before the first command had received its reply. If an application had omitted a state check at any asynchronous entry point, the second command could overwrite stored signing parameters while the original review screen remained unchanged.
The company classifies this as a time-of-check to time-of-use race condition. It breaks the hardware wallet's trusted-display guarantee because a valid signature may no longer cover the operation the user actually inspected. The weakness did not expose the seed phrase or private key; it could instead misuse the protected key to sign a different set of parameters.
What an attacker would have needed
The flaw was not remotely exploitable against an idle device. An adversary needed control of the APDU exchange, which could come from a malicious or compromised wallet application, a hostile page with an active WebHID or WebUSB connection, or malware on the connected computer. The user also had to open an affected application and approve the operation shown on screen.
Impact depended on the command involved and on validation elsewhere in each application. The bulletin does not say every installed app could sign any arbitrary transaction. Applications that checked their state consistently rejected interleaved commands, while exposure arose where an app built with the affected SDK path had left an asynchronous entry point unguarded.
Ledger Donjon says it has no evidence that the issue was exploited against users. That distinguishes demonstrated technical reach from a confirmed incident: the trusted-display failure was serious, but the disclosure is not evidence of widespread device compromise or known theft. Ledger also says the device operating system and firmware were not the source of the defect.
Why both 1.22.2 and 1.22.3 appear in the record
Remediation arrived in two layers. Ledger first hardened individual applications so every asynchronous handler validates its state and refuses a new command while a review is pending. Ethereum app 1.22.2 was the first release with those application-level guards. Secure SDK 26.6.1 then added a common latch that rejects an interleaved command before application code can receive it, and apps were rebuilt against that SDK.
Version 1.22.2 addresses the desynchronization class documented in LSB 023. Ethereum app 1.22.3, however, fixed a separate set of issues, including a swap path that could accept an ERC-20 approval in place of a transfer. Installing 1.22.2 therefore answers one bulletin only; the practical minimum at publication time is 1.22.3 or any later version offered by the official manager.
Public dates are not perfectly aligned. The GitHub release page shows 1.22.2 on 24 August, while Ledger Donjon's internal timeline says the first application-level fixes were published and verified on 13 August. That discrepancy does not change the user's next step: obtain the current signed application through Ledger Wallet, the product formerly known as Ledger Live.
What device owners should verify
A firmware update alone does not prove the vulnerable application code has been replaced. Owners should use the official application manager to update Ethereum to at least 1.22.3 and install updates for every other blockchain app they use. The installed version should then be checked on the signer itself, not only in the desktop interface.
Until applications are current, avoid approving operations from unfamiliar sites or unofficial wallet software. After updating, the device screen remains the final review point: the destination, asset, amount and permission type must match the intended action. Any request to enter a recovery phrase on a website or computer is unrelated to this update and should be treated as a separate scam warning.
Ledger advises third-party application developers to audit every asynchronous handler and rebuild against Secure SDK 26.6.1 or later. Users do not need to inspect APDU state machines; the durable routine is to update both firmware and installed apps from the official source, verify versions on-device and reject any operation whose outcome cannot be clearly understood from the trusted display.
