Ledger shipped Ethereum app 1.22.2 in mid-August 2026 behind a two-word changelog, then spent late August arguing with the researchers who described what it fixed. OneKey's Anzen team reproduced a transaction-replacement attack against the previous version. No funds are known to have been lost. The governance question — a silent fix on a device that only protects users who choose to update — outlasts the bug.
A hardware wallet makes exactly one promise. Your private key never leaves the device, and the small screen on that device shows you what the key is about to sign. Everything else — the app, the laptop, the browser extension, the website — is assumed to be hostile. The screen is the last honest surface in the chain.
The flaw Ledger patched in Ethereum app version 1.22.2 broke that promise without touching a single cryptographic primitive. The key stayed secret. The signature was valid. The device just could not guarantee that the transaction it displayed was the transaction it signed.
There are two ways a hardware wallet can present a transaction. Blind signing shows you a hash — a meaningless string that you approve on faith, trusting that the dApp requesting it is honest. Clear signing decodes the transaction and shows it in human terms: this contract, this token, this amount, this recipient.
Clear signing exists because blind signing has drained a great many wallets. The canonical loss is a user who believed they were approving a small transfer and had in fact granted an unlimited spending allowance on a token to an attacker's address. Clear signing is the industry's answer to that, and it is the feature the entire self-custody pitch has been built on for several years.
Which is why a flaw in the display path is not a lesser class of bug than a flaw in the key handling. It is the same class. If the screen can be made to disagree with the signature, the security model has been defeated by other means.
The device communicates with the host computer using APDU commands — short, structured messages, the same protocol family used by smartcards. A transaction is not delivered as one atomic blob. It arrives as a stream of commands: here is the data, here is more of the data, now display it, now sign it.
The vulnerability lived in the handling of that stream. According to Crowdfund Insider's account of the fix, a malicious dApp with the right access could send competing commands during the review window — the interval while a human is reading the screen and reaching for the confirm button. Because the display logic and the underlying signing buffer were not locked to each other for the duration of that window, the buffer could be changed after the screen had been drawn. The user reads one transaction and authorises another.
That is a race condition in the ordinary computer-science sense: the outcome depends on the arrival order of concurrent operations, and the code did not enforce an order. It is worth being precise about what this is and is not. It is not a key extraction. It is not a signature forgery. It is not a cryptographic weakness. It is a state-management failure in the layer that is supposed to keep the human and the machine looking at the same thing — a UI-integrity failure. Most of the coverage has reported it as a vulnerability without separating those categories, and the distinction matters, because it determines what a fix has to do.
The fixes in 1.22.2 read exactly as you would expect once you see it that way. Per Crowdfund Insider, the app now rejects signature commands received while a review is pending, fixes the signing mode at the start of the operation, and rejects changes arriving during continuation fragments. Each of those closes the window rather than adding cryptography, because there was never anything wrong with the cryptography. CryptoSlate reports the wider change as a roughly 26-commit security-hotfix review closing on the order of ten concurrency-safety issues — which suggests the team treated the reported flaw as a symptom of a class rather than a one-off.
The flaw was found internally by Donjon, Ledger's own security research team, using AI-assisted tooling. Whatever one concludes about the disclosure fight, the bug was located by the vendor, not by an outside researcher.
Ledger shipped 1.22.2 in the middle of August 2026. Sources differ slightly on the exact day — crypto.news reports 13 August, other accounts put it at around 12 August — and nothing analytically important turns on which is right. What matters is the release notes, which in full read: security issues.
That is a defensible choice in isolation. Withholding detail until users have updated is standard practice across the software industry, and publishing a precise description of a signing-path race condition on day one would have handed a blueprint to anyone who had not yet thought of it.
It is a weaker choice on this specific class of product, for a reason that has nothing to do with responsible disclosure norms. A hardware wallet is not a cloud service. There is no server-side patch, no forced update, no fleet the vendor can remediate on the owner's behalf. Every protected user is a user who personally chose to open Ledger Live and apply an update. On a device with that update model, the changelog is not documentation — it is the entire distribution mechanism for urgency. A two-word note gives an owner no reason to prioritise the update over the several other pending updates on their machine.
The uncomfortable observation about the fortnight that followed is that the public argument did the job the changelog did not. Most Ledger owners who know about this issue learned about it because a fight broke out, not because they were told.
Around 21 to 23 August, TestMachine published findings on the flaw, produced using its autonomous scanner Azimuth. TestMachine says it shared and verified the findings with Ledger and declined a bounty. Ledger's position is that the issue was already fixed and that users on the current version had never been exposed.
The escalation came when OneKey — a competing hardware wallet vendor — had its Anzen team reproduce a transaction-replacement attack in lab conditions against Ethereum app 1.22.1, the version immediately preceding the fix. Ledger disputed the framing rather than the reproduction. Chief Technology Officer Charles Guillemet characterised the public disclosure as fear-mongering, and on the reproduction was blunt.
“No exploitation in the wild. Running an exploit against an old version after the fix has shipped is a lab exercise, not a finding. — Charles Guillemet, Ledger CTO, as reported by crypto.news”
Take that argument seriously, because on its own terms it is correct. Demonstrating a patched bug against the unpatched version proves the bug was real, which nobody disputes, and proves nothing about the exposure of anyone who has updated. And OneKey is a direct competitor, which is a legitimate thing to weigh when assessing why the reproduction was published and promoted.
The counter is equally solid, and it is about population rather than proof. On a device that updates only by owner action, the unpatched version is not a historical artifact — it is a live installed base of unknown size. A reproduction against 1.22.1 is a statement about the users who have not updated, and Ledger has published no figure for how many that is. Guillemet's framing is accurate about the patched population and silent about the unpatched one. Both things can be true, and the disagreement is really about which population the vendor owes a duty of warning to.
Three things should not be reported as resolved, because they are not.
The practical instruction survives all of that intact, and it is the same regardless of whose account of the fight you find more persuasive: open Ledger Live and confirm the Ethereum app is on 1.22.2 or later. It costs a minute and it moves you out of the only population still in dispute.
The larger lesson is a governance one, and it will outlive this particular bug. Hardware wallets have built a security model that depends on two things the vendor does not control: that the owner reads the screen, and that the owner applies the update. Both are user actions. A vendor that ships a fix behind a generic changelog has quietly opted out of the second one — and then finds, as Ledger did, that the news travels anyway, through a channel it likes considerably less.
Ledger's position is that users on the current version were never at risk from this issue, and the reproduction published by OneKey was performed against the earlier 1.22.1. No party has demonstrated the attack against 1.22.2. If you are unsure which version you have, check the Ethereum app in Ledger Live and update if it is below 1.22.2.
We write about the mechanisms underneath crypto security and governance — finality rules, staking concentration, fork risk — rather than price action.
Read more in Crypto$26 billion. $31 billion. $38.17 billion. Tokenized Treasuries at $6.8bn, $12.88bn, $15bn, $16.21bn. All published in 2026, all defensible, none reconcilable without knowing the date and the definition.
Coverage fixed on the $75 million exemption. The consequential provision is a conditional safe harbor that would let a crypto asset stop being subject to an investment contract — and a preemption clause almost nobody has read.
Staking participation hit a record 33.98% of ETH supply this month. Six researchers, including the Ethereum Foundation's Justin Drake, are proposing to burn validator rewards to zero if it reaches 50% — and their argument is not about yield.