- Ledger has now published Ethereum app version 1.22.3, after two further signing flaws survived the previous release. Owners who already updated to 1.22.2 need to update again.
- The original path, which Ledger tracks as LSB-023, was demonstrated publicly on 22 August by OneKey, a rival hardware wallet maker. Ledger says the demonstration ran against version 1.22.1 and that it had already closed that path in 1.22.2 on 13 August.
- Ledger has said publicly that no user was hacked and that it has found no evidence of exploitation in the wild. That is the company’s own account, and no independent confirmation of it has been published.
The screen on a hardware wallet exists for one reason: to be the last thing that tells you the truth when your computer might be lying. A fix now shipped in Ledger’s Ethereum app addresses a case where the screen and the signature could come apart.
Owning crypto yourself means the device in your hand is the final check on every payment you make. If it can display one payment and approve a different one, that check stops working, and you would have no way of knowing at the moment you pressed the button. It has taken Ledger two releases to close this off, so the useful action is small and immediate: check which version of the Ethereum app you are running and update it before your next transaction.
What signing actually is
Your ether doesn’t live inside the device. It sits on the Ethereum network, a public record, and what you own is a : a secret number that proves the coins are yours and authorises them to move.
Every time you send funds or approve something on a decentralised app, that key produces a signature over the exact details of the transaction: where it goes, how much, and what the receiving contract is permitted to do. Change any of those details and the signature no longer matches. That’s the whole security model.
A hardware wallet keeps the key on a separate chip that never hands it to your computer. Your laptop can build a transaction and pass it over, but only the device can sign it, and only after you look at the details on its own small screen and press a button. The screen is the part that matters. It’s meant to be the one surface a compromised computer cannot rewrite.
What the code change describes
According to Ledger‘s public code history, as reported by CryptoSlate, the app previously allowed a new signing command to arrive while a transaction was still under review. In the path set out by the researchers, a second command could replace the transaction sitting in the device’s memory without triggering a fresh review, so the original details stayed on screen while the device prepared to sign the substituted data. Pressing approve returned a signature for the replacement.
Two official fix commits are cited. One makes a new signing command tear down an active review and return an error rather than quietly proceeding. The other adds state checks, because the approval callback previously signed without confirming the app was still in the signing state it expected. Version 1.22.2 refuses a new signing session during an active review, and rejects an approval when the state no longer matches.
That release did not finish the job. On 25 August Ledger published version 1.22.3, closing two more signing flaws: one that could keep operations out of the review shown on the device, and one that could authorise a approval in place of the payment the user was expecting. A token approval is the permission that lets a contract move funds out of your wallet later, rather than a single transfer now, so substituting one for a payment leaves a door open behind it.
The original demonstration needed a decentralised app with WebHID access, the browser interface that lets a website talk directly to a connected USB device. That’s a real requirement rather than a formality: something already talking to your device had to be involved.
Who demonstrated it, and what Ledger says
Attribution has shifted since the first reports. Decrypt credits the demonstration to OneKey, which makes hardware wallets of its own and therefore competes with Ledger directly; the earliest coverage named a security firm called TestMachine. We can’t reconcile those two accounts from what’s public, and it may be that both were involved. Either way, a demonstration of a rival’s flaw published by a competitor is an interested source, and worth reading as one, in the same way a company’s statement about its own product is.
Ledger has since put dates and version numbers to it. The company says OneKey reproduced the bug, which it tracks as LSB-023, against Ethereum app version 1.22.1, and that the path had already been closed in 1.22.2 on 13 August. “No Ledger user was hacked,” its security team said, describing the demonstration as a laboratory reproduction involving outdated software and saying it had found no evidence of exploitation in the wild. Chief technology officer Charles Guillemet drew the same distinction between a flaw reproduced in a lab and one used against a real holder.
What we can and can’t stand behind
We have not read a primary source for this. There is no researcher write-up in front of us, only CryptoSlate’s account of the code history and the company’s statements, so we are one step removed from all of it and reporting it as such.
Confirmed, on that basis: the version numbers and their dates, that official commits describe restricting new signing sessions and adding state checks, and that a further release on 25 August closed two more signing flaws. Asserted by interested parties, on both sides: the researchers’ description of how the substitution would run and that it was validated on a Ledger Flex, and Ledger’s position that the demonstrated path was already patched and that nothing was hacked. Still not established anywhere in the reporting: any independent confirmation that nobody was affected, and who found the two flaws that 1.22.3 fixed, which is the difference between a company auditing its own work and outside pressure doing it for them.
Patched before exploited is a different story
When we covered the BitBox firmware flaws, the point was that the flaws were found and fixed before anyone lost money, which is disclosure working roughly as designed. Ledger’s account of this puts it in the same shape, and on the timeline it has given, the outcome for holders is the good one. Compare it with the Coldcard episode, where owners spent days unable to find out whether their own device was affected, and the difference is obvious: a fix that ships with a version number you can check is a far better position for a holder than a warning with no list attached.
The qualifier is that it took two goes. A patch that has to be followed twelve days later by another patch in the same part of the same app tells you the first pass at the signing logic was not complete, and the honest reading is that the review of this code is still ongoing rather than finished.
That isn’t a clean bill of health for hardware wallets generally. Firmware is software, software has bugs, and the reasonable conclusion is the one Changpeng Zhao offered after Coldcard: don’t put everything behind one device. Our guide to self-custody covers how to spread holdings across more than one setup.
What to do, practically
Open Ledger Live, go to the device’s app manager, and look at the version listed next to Ethereum. If it isn’t 1.22.3 or later, update it there. Updating to 1.22.2 is no longer enough, so this applies even if you acted on the first round of coverage. App updates on these devices sometimes require removing and reinstalling the app, which does not touch your coins or your key, but do make sure your is written down and accessible before you start, because that phrase is the only thing that restores access if anything goes wrong with the device itself.
Do the update through Ledger Live or ledger.com directly. Wallet update notices are a favourite hook for phishing, and an email or a pop-up telling you to click through to a firmware page deserves no trust at all. If you are choosing between devices rather than fixing one, our Trezor and Ledger comparison sets out where they differ.
What to watch
Ledger has now supplied most of the paperwork that was missing a week ago: a tracking reference, the version the demonstration ran against, and the dates of both fixes. What it hasn’t supplied is anything a holder can use to verify the central claim that no one was affected, and that is unlikely to arrive from the company itself.
The question now is whether 1.22.3 is the end of it. Two rounds of signing fixes inside a fortnight suggests other people are still reading this code closely, and a third release would say the review has further to run. Worth following alongside that: whether the researchers’ full write-up holds up once independent eyes are on it, particularly the claim that the substitution could happen with no change at all on the device screen. That detail carries the whole story, it rests on a competitor’s account of its own testing, and Ledger’s version of events now contradicts part of the framing around it.