Ledger is disputing OneKey’s claim that it “hacked Ledger” after the rival wallet maker reproduced a transaction substitution flaw in a lab. The bug was real, but the public framing is doing a lot of heavy lifting.
- Lab reproduction, not a live breach: OneKey reproduced the flaw on Ledger Ethereum app 1.22.1.
- Wrong-signing risk: The issue could make a user approve transaction A while the device signed transaction B.
- Ledger says it was already fixed: The company says 1.22.2 and later versions added safeguards before OneKey went public.
- Keys stayed put: Ledger says the bug did not expose seed phrases or private keys.
On Aug. 27, OneKey founder Yishi Wang said the company’s Anzen security team completed the attack in a laboratory and declared, “we hacked Ledger.” Ledger’s Chief Technology Officer Charles Guillemet pushed back just as hard: “reproducing an already-patched bug is not ‘hacking Ledger’.”
Both statements can exist in the same room, but they mean very different things.
OneKey’s team reproduced a transaction substitution attack, the kind of failure hardware wallets are supposed to prevent. In plain English, the user thinks they are reviewing and approving one transaction on the device screen, but the wallet ends up signing a different one. If a hardware wallet’s trusted display can be fooled, the whole point of the device starts wobbling.
Ledger says the weakness sat in its Secure SDK and application-level command handling, not in the device firmware or the secure element. The secure element is the protected chip meant to keep private keys isolated. Ledger says that chip was not cracked, seed phrases were not exposed, and no private keys were extracted.
That distinction matters. This was not a dumb “the chip got popped, everyone panic” moment. It was a state-handling flaw in how the app processed incoming instructions while the user was still reviewing a transaction.
Ledger classifies the issue as a time-of-check to time-of-use race condition. That means the app checked a transaction, the user reviewed it, and then a second command slipped in before signing finished. The result could be a mismatch between what the user saw and what was actually signed.
Ledger says the affected apps receive low-level instructions called APDU commands from wallet software, webpages, or other interfaces. In this case, an app could accept a second APDU while a previous operation was still being reviewed on the device screen.
The threat model is ugly, but not magical. Ledger says an attacker would need control of communications between the Ledger application and the host. Possible routes include malware, a compromised wallet app, or a hostile webpage using WebHID or WebUSB. Those browser interfaces can let a site talk to connected hardware devices, which is handy when everything is honest and a headache when it is not.
Ledger says the flaw could not be used remotely against an unplugged device. That may sound obvious, but it matters: this was not a worm that could reach across the internet and steal funds from a wallet sitting on a shelf. It needed a bad host-side environment.
The timing is where the dispute gets sharp. Ledger says the first application-level fix appeared in Ethereum app 1.22.2, which it says added safeguards before OneKey publicly described the reproduction attempt. Ledger also released Secure SDK 26.6.1 on Aug. 21, saying it blocked interleaved commands before they reached individual Ledger device applications directly.
Ledger now recommends Ethereum app 1.22.3 or later, because that version includes the broader SDK protection and also addresses another transaction-display flaw. Ledger says users should open Ledger Live, install the latest device applications, and verify the Ethereum app version on the hardware wallet itself.
That last part is not optional busywork. Ledger says updating firmware alone does not replace applications built with an affected SDK. If the app itself is old, the risky logic can still be there. Crypto security has a talent for hiding the foot-gun in the one layer people forgot to check.
For third-party developers, Ledger’s message is blunt: review your state handling and rebuild with Secure SDK 26.6.1 or later. Applications compiled with affected SDK releases were expected to rely on their own state checks to reject commands arriving during an active review. If that logic is sloppy, the display can become theater.
OneKey reproduced the bug against Ledger Ethereum app version 1.22.1 in laboratory testing. Ledger says the weakness was introduced in August 2025 and affected SDK versions through 26.6.0, though that date is Ledger’s own claim and not independently verified in the supplied material.
That is why the “we hacked Ledger” line is more rhetoric than precision. OneKey’s lab reproduction shows the flaw is real. Ledger’s response is that reproducing a patched bug on an outdated app is not the same as breaking current defenses or compromising customers in the wild. Those are different levels of severity, and the distinction is not corporate hairsplitting.
Ledger says it has found no evidence that the flaw was exploited against users or that it caused cryptocurrency losses. That does not make the bug harmless. It means the evidence currently available does not show active abuse or confirmed theft tied to this specific issue.
There is also a broader lesson here for anyone who treats hardware wallets like sacred objects. The secure element may be intact, but if the software path between the host and the device can be manipulated, the user can still be tricked into signing the wrong thing. The chip is only one part of the trust chain.
That is why transaction substitution attacks matter so much. They do not need to steal keys to cause damage. They only need to convince a user that one thing is happening while another thing is being signed. For swaps, approvals, and contract interactions, that can be enough to drain funds or approve something the user never intended.
This also fits a pattern the industry keeps stumbling over. Hardware wallet makers continue to find edge-case failures in display logic, address handling, and app-state management. BitBox recently patched two separate flaws affecting firmware installation and Bitcoin address handling, with no confirmed exploitation reported there either. Different product, different bugs, same basic reminder: “offline keys” is not the same as “perfect security.”
The real debate here is not whether a bug existed. It did. The debate is how to describe a reproduced flaw that was already patched before the public chest-thumping started. Responsible disclosure is one thing. Turning a lab reproduction into a victory lap is another. Security research deserves credit; sloppy marketing with a cape on it does not.
The blunt takeaway is simple. Hardware wallets are only as trustworthy as the software state behind their screen. If the device can be made to show one transaction and sign another, then the “what you see is what you sign” promise is already in trouble.
Key questions and takeaways
-
Was Ledger actually hacked?
Ledger says no. OneKey reproduced a known flaw in an older Ledger Ethereum app version in a lab, but Ledger argues that reproducing an already-patched bug is not the same as compromising current systems. -
Did the flaw expose private keys or seed phrases?
Ledger says it did not. The issue affected transaction display and signing state, not the secure element or key material. -
Was anyone known to have lost money?
Ledger says it found no evidence of exploitation or losses, and no confirmed thefts were publicly tied to this issue in the supplied material. -
What versions matter here?
OneKey reproduced the flaw on Ethereum app 1.22.1. Ledger says 1.22.2 added safeguards, Secure SDK 26.6.1 broadened the protection, and Ethereum app 1.22.3 or later is the safer target. -
What should users do now?
Open Ledger Live, update the device applications, and check the Ethereum app version on the hardware wallet itself. Ledger says a firmware update alone is not enough if the app was built with an affected SDK. -
Why does this matter if the bug was patched?
Because it shows how hardware-wallet trust can fail at the software layer even when keys stay protected. If the app can be tricked into swapping signing context, the screen stops being a reliable guardrail.
“Reproducing an already-patched bug is not ‘hacking Ledger’, ” said Ledger CTO Charles Guillemet.
OneKey founder Yishi Wang said on Aug. 27 that the team had completed the lab attack and claimed, “we hacked Ledger.”
Further reading
A few related resources on wallet security, hardware risk, and the bigger industry backdrop.
