A Bitcoiner can tolerate an infected laptop better than most computer users. The seed stays inside a dedicated signer while the transaction appears on a separate screen. Physical confirmation puts one more barrier between malware and the money. That model rests on a simple sentence: what you see is what you sign. Ledger Security Bulletin 023 describes a flaw class that could break that sentence. The patch is available, but current firmware alone does not prove that the vulnerable application code has been replaced.
The screen and signature could disagree
Ledger applications receive commands from a connected computer through a protocol called APDU. Some operations arrive in several chunks. The application processes a command and shows transaction details, then waits for the user to approve or reject the operation.
The disclosed weakness sat in that waiting period. The shared Ledger Secure SDK accepted a new command while the first command was still awaiting a reply. Signing parameters remained in global memory for the approval callback to use later. An application that failed to reject every unexpected command could let a hostile host overwrite part of that state while the review screen stayed unchanged.
The operator could read one destination and amount, press approve, and receive a signature covering different parameters. The seed never left the Secure Element, and the user genuinely approved what the device displayed. Those safeguards would still fail to save the transaction.
This is a time-of-check to time-of-use bug. The check happens when the user reads the screen. The use happens when the device produces the signature. If code can change the transaction between those moments, careful verification becomes theater.
Ledger says exploitation required control of the command exchange. A malicious wallet or malware on the connected computer could provide that control. So could a hostile page with WebHID or WebUSB access. The company reports no evidence that attackers exploited the issue against users. Exposure also depended on the individual device application. Apps that consistently checked their state were unaffected.
The fix lives in applications, not only firmware
The scope matters because ‘my firmware is current’ sounds reassuring but answers the wrong question. Ledger says the flaw was absent from the device operating system and firmware. The faulty SDK code had been compiled into applications installed on the signer.
Ledger first hardened affected applications so every asynchronous entry point rejected commands that arrived during a pending review. It then fixed the shared input and output layer in Ledger Secure SDK version 26.6.1, released August 21. New SDK logic places a latch around an accepted command and refuses additional commands until the application replies. Ledger says it rebuilt and republished applications against that corrected SDK.
The original bulletin tells users to update applications through Ledger Wallet and verify the application version on the signer. A firmware update cannot establish that corrected app builds are present. Third-party app developers must review their own handlers and rebuild against SDK 26.6.1 or later.
On August 27, rival hardware wallet maker OneKey said its Anzen team reproduced the transaction-replacement scenario against an older Ethereum application build. A contemporaneous review describes an interested-party claim with no published proof in the retrieved material. Reproducing an older vulnerable build also cannot establish whether the current patch can be bypassed. The claim supports the plausibility of the mechanism. It does not show that updated devices remain exposed.
Run the application audit before the next signature
Handle this as a controlled update. Panic invites hurried downloads and sloppy checks. Do not begin signer maintenance from the same browser tab that delivered the warning. Start from the vendor's official support page and confirm that your recovery backup is available. Keep the signing workstation quiet while you work.
1. Inventory every Ledger device and every installed application you use. A spare signer with an old app remains part of the attack surface if it can sign from the same accounts.
2. Install the current Ledger Wallet release from the official source. Avoid search advertisements, support messages, direct messages, and emailed download links.
3. Use Ledger Wallet to install the latest available build of each required device application. A current device operating system does not replace this step.
4. Verify application versions on the signer itself where the device exposes them. Record the check date and version beside your custody maintenance notes.
5. For third-party device applications, confirm that the developer has rebuilt against Ledger Secure SDK 26.6.1 or later. If you cannot verify that, stop using the app for signing until the developer publishes a clear answer.
6. Close browser tabs and wallet programs that do not belong in the signing session. Revoke unnecessary WebHID or WebUSB permissions. Refuse fresh device connections from unsolicited pages.
7. After the update, build a small Bitcoin transaction and inspect every field the signer presents. Confirm the destination, amount, fee, and change behavior. A test payment cannot prove the old flaw is gone, but it can expose broken workflow assumptions before a treasury-sized transfer.
Ledger's own signer threat model names user consent as a primary security objective. Its secure-display guidance treats the separate screen as protection against a compromised computer. Those claims identify the boundary this flaw threatened. A hardware signer holds the seed and acts as an independent transaction referee.
The PSBT coordinator trap
Imagine Maya manages a small Bitcoin treasury. She builds a partially signed Bitcoin transaction on her everyday laptop, connects a Ledger device, and reviews the payment on the signer. She has trained herself to distrust the laptop display. Before approving, she checks the destination and amount on the device.
That habit is correct. Under the disclosed failure class, however, a compromised coordinator could control the APDU exchange and try to alter pending application state after the trusted screen was drawn. Maya could follow the rule perfectly and still sign parameters that the screen did not show, but only if the device application lacked the necessary state checks.
Screen verification still matters, but the ritual inherits the security of the code that implements it. Maya should keep the signer application current and use a dedicated coordinator instead of her daily browsing machine. She should also remove unneeded device permissions and refuse to sign when application provenance is unclear. For large spends, a second signer from an independent implementation adds another boundary. It should verify the same transaction through a separate code path without relying on the first device's output.
Bitcoin finality gives no credit for an honest click on a dishonest state. Once a valid signature authorizes the wrong transaction and the network confirms it, good intentions cannot reverse the spend.
Final Thoughts
Ledger found and patched this flaw before reporting any user exploitation. Corrected applications still need to reach devices sitting in drawers. Check every signer that can move meaningful bitcoin, including backups and rarely used treasury devices. Keep device permissions narrow and treat application versions as custody-critical state. The host remains untrusted even when the signer is current. A trusted screen is only as honest as the code behind it.
