A hardware wallet maker just showed the industry how a signing bug can slip past a screen a user is staring at. On August 28, 2026, OneKey’s internal security team, called Anzen, published a lab reproduction of what it labeled a “transaction replacement attack” against Ledger’s Ethereum app. The flaw let a compromised host swap the transaction a Ledger device actually signs while the screen kept displaying the one the user approved. No customer lost funds, and Ledger says it had already shipped a fix two weeks before OneKey went public. But the episode reopened a debate that has trailed hardware wallets for years: how much can a screen really be trusted when the software feeding it can be manipulated.
The dispute matters beyond a single vendor’s bug tracker. Ledger remains one of the two dominant names in hardware wallet security, and its Ethereum app processes signing requests for a large share of self-custodied ETH and ERC-20 transfers. A bug that lets displayed and signed data diverge strikes at the one guarantee a hardware wallet is supposed to provide: what you see is what you sign. This piece breaks down what actually happened, how the exploit worked at a technical level, why Ledger disputes the word “hack,” and what it means for an industry that lost more than $3.6 billion to exploits and stolen credentials between January 2025 and July 2026, according to CoinGecko data cited by CNBC.
What OneKey Actually Reproduced
OneKey’s Anzen team says it ran a lab test against Ledger’s Ethereum app version 1.22.1, built on Secure SDK releases up to 26.6.0. The team recorded a device that displayed one transaction on screen, “Transaction A,” while ultimately signing a second transaction, “Transaction B,” that the user never saw. OneKey founder and CEO Yishi Wang went public with the finding on social media, framing it as proof that a Ledger device could be tricked into signing something other than what its owner approved. The claim spread fast across crypto trading circles precisely because it undercuts the core sales pitch of every hardware wallet: an air-gapped, tamper-resistant screen that shows the truth no malware can fake.
Ledger’s response, published through its own security channel, pushed back hard on the framing. The company said the underlying issue had already been identified and patched in Ethereum app version 1.22.2, released August 13, 2026, roughly two weeks before OneKey’s demonstration went public. Ledger also pointed to a separate researcher, publishing under the handle “TestMachine,” who had documented a closely related flaw on August 22. In Ledger’s telling, OneKey reproduced a bug in an outdated, already-fixed app version rather than uncovering a live threat to current users. Independent outlets including Cointelegraph and Blockonomi corroborated the patch timeline, reporting that app 1.22.2 shipped before OneKey’s public disclosure.
Inside the Race Condition: How a Display Can Lie
The mechanics matter because they explain why this class of bug is so hard to catch through normal code review. Ledger’s Ethereum app processes signing requests through a sequence of host-to-device commands, known as APDUs (application protocol data units). A host application, such as a compromised browser extension, malicious dApp front end, or infected desktop client, sends transaction parameters to the device in stages: first populating a buffer, then triggering the display of that buffer’s contents, then requesting the user’s physical confirmation.
The vulnerability OneKey reproduced exploited a timing gap between two of those stages. If a malicious host sent a second APDU command that overwrote the transaction buffer while the original transaction was still rendered on screen, the app’s display logic and its signing logic could fall out of sync. The screen kept showing the first transaction. The signing engine, however, operated on whatever sat in the buffer at the moment the user pressed the confirm button, which could by then be the attacker’s substituted transaction. Security researchers describe this as a classic time-of-check-to-time-of-use flaw, adapted to embedded hardware rather than a server process.
Host -> Device: SET_BUFFER(txA) // legitimate transaction
Device -> Screen: RENDER(txA) // user sees txA
Host -> Device: OVERWRITE_BUFFER(txB) // malicious command, sent mid-review
// display NOT refreshed
User: press CONFIRM (believes approving txA)
Device -> Signer: SIGN(current_buffer) // signs txB, not txATwo things kept this from becoming a live-fire disaster. First, it requires a compromised or malicious host, meaning the attacker needs control over the computer, browser, or dApp interface the victim is using, not just proximity to the hardware device itself. Second, it requires precise timing, since the malicious command has to land inside the narrow window between display and confirmation. Ledger’s fix, shipped in app 1.22.2, introduced state checks that block signing whenever the buffer content and the last-rendered display fall out of sequence, closing that window regardless of what a malicious host attempts.
The Patch Timeline, Version by Version
Multiple outlets, including Cointelegraph, Crypto News, and CryptoSlate, converge on a consistent sequence of dates and version numbers. The table below lays out the disclosure and patch timeline as reported.
| Date (2026) | Event |
|---|---|
| Aug 13 | Ledger ships Ethereum app version 1.22.2, adding state checks that close the buffer/display desync path |
| Aug 22 | Independent researcher “TestMachine” publishes an earlier write-up describing a related signing flaw |
| Aug 27 | Ledger discloses two additional signing bugs, unrelated to the buffer desync issue, fixed in app version 1.22.3 |
| Aug 28 | OneKey’s Anzen security team publicly demonstrates the “transaction replacement attack” against app version 1.22.1 |
| Sep 5 | OneKey issues a formal statement recapping the lab test and its methodology |
| Sep 18 | Coverage continues as Ledger reiterates that no user funds were affected and the flaw was patched pre-disclosure |
Note the layering: app 1.22.2 fixed the specific command-interleaving path that OneKey later showcased, while app 1.22.3, five days after that patch, closed two separate signing bugs Ledger disclosed on its own. CryptoSlate’s reporting is explicit on this point, distinguishing the bug OneKey reproduced from the additional issues fixed a version later. That distinction is easy to lose in social media summaries but matters for anyone deciding whether to trust the “already patched” defense.
Ledger’s Defense: The Fix Predates the Disclosure
Ledger’s public messaging centered on three claims: the bug lived in an outdated app version, the fix predated OneKey’s disclosure by roughly two weeks, and the company has found no evidence of the flaw being exploited against a real user. All three claims are corroborated by independent outlets that reviewed Ledger’s security bulletin and version history. Ledger also stressed that the fix required a software update through Ledger Live, not a firmware reflash, meaning any user who kept their Ethereum app current after August 13 was never exposed to the version OneKey tested.
That framing shifts the story from “Ledger got hacked” to “Ledger’s patch cadence worked as intended, and a competitor demonstrated why patching matters.” It is a more mundane story, but also a more useful one for the industry: hardware wallets are not immune to the update-lag problem that plagues every other category of consumer security device. A secure element chip can be flawless and a device can still ship a signing app with a timing bug, because the vulnerability sits in application logic layered on top of the hardware root of trust, not in the chip itself.
Why a Rival Company Ran the Test
OneKey is a direct Ledger competitor in the self-custody wallet market, and its decision to publicize a rival’s patched bug drew accusations of opportunism from parts of the crypto community. OneKey’s counter-argument, voiced by founder Yishi Wang, is that publishing reproducible security research, even against a competitor’s product, is standard practice in the broader security industry and serves users who may still be running outdated firmware or apps. OneKey has built its brand partly around an open-source positioning, arguing that auditable firmware lets outside researchers catch exactly this kind of buffer-and-display desync before it reaches production.
Whether or not OneKey’s timing was self-serving, the underlying test is reproducible and technically sound according to multiple outlets that reviewed it, including Forklog, Odaily, and Crypto News. The bigger question the episode raises is structural: does a closed-source secure element with proprietary signing logic actually offer stronger real-world guarantees than an open-source design that trades some manufacturing secrecy for community auditability? Ledger has defended its closed architecture for years on the grounds, published on its own security pages, that its Secure Element chips block firmware extraction and hardware-level tampering that fully open designs sometimes struggle to match. This incident does not settle that debate, but it hands OneKey a concrete data point to cite in it.
A Pattern, Not an Isolated Bug
The Ledger disclosure lands in the middle of an unusually rough September for crypto custody. Within the same three-week window, a Blockstream-operated Bitcoin sidechain, a DeFi bridge, and a smart-contract wallet module all suffered separate, unrelated security failures. None of these incidents involved Ledger hardware, but together they illustrate a theme that runs through 2026’s security news: the weak point in crypto custody keeps moving from raw cryptography, which remains sound, toward the software layers wrapped around it, including bridges, wallet modules, and now signing-app display logic.
| Incident | Date | Loss / Impact | Root Cause |
|---|---|---|---|
| Ledger Ethereum app 1.22.1 | Aug 28, 2026 (disclosed) | $0 confirmed loss (lab reproduction only) | Race condition between display buffer and signing engine |
| Liquid Network (Blockstream sidechain) | Sep 6-7, 2026 | ~$320M stolen, roughly 85% later returned | Custody wallet compromise, per TRM Labs |
| Safe wallet module (rsETH/Kelp DAO) | Sep 15, 2026 | ~$7.8M | Malicious Multicall module authorization flaw |
| Symbiosis BridgeV2 | Sep 11, 2026 | $336K realized (of $46.1B notional mint) | Bridge contract message-validation flaw |
| Aggregate crypto losses | Jan 2025 – Jul 2026 | $3.63B+ | Mix of exploits and stolen credentials, per CoinGecko |
The contrast is instructive. The Liquid Network and Symbiosis incidents cost real, confirmed money because they targeted custody infrastructure directly. The Ledger bug, by comparison, cost nothing in practice, because it required both an already-compromised host machine and a patch window that closed before public disclosure. That gap is exactly what separates a demonstrated vulnerability from an actual breach, a distinction that gets flattened in social media headlines but matters enormously for risk assessment.
How This Compares to Ledger’s Past Security Episodes
Ledger has weathered security controversies before, and this one reads differently from the two most-cited prior episodes. In December 2023, Ledger’s Connect Kit, a JavaScript library that thousands of decentralized apps embedded to talk to Ledger devices, was compromised through a supply-chain attack after a former employee’s npm credentials were phished. Malicious code was pushed live and actively drained funds from users interacting with infected dApp front ends before Ledger and ecosystem partners pulled the compromised package. That was a live, exploited supply-chain breach with real victims.
Earlier in 2023, Ledger also faced backlash over Ledger Recover, an opt-in feature that would let users split their seed into encrypted shards held by third-party custodians for account recovery. That controversy was about trust and design philosophy rather than an active exploit: critics argued that any firmware pathway capable of exporting seed material, even encrypted and opt-in, weakened the “seed never leaves the device” guarantee that hardware wallets are built on.
The 2026 transaction-replacement bug sits closer to a conventional software vulnerability: a specific, patchable flaw in one app’s signing logic, caught, fixed, and only later demonstrated by an outside party. It lacks the live exploitation of Connect Kit and the architectural controversy of Recover. But it reinforces the same underlying lesson those two episodes taught the market: a hardware wallet’s security depends on the entire stack around the secure element, including third-party libraries, app firmware, and update discipline, not on the chip alone.
What Users Should Actually Do
For Ledger owners, the practical takeaway is narrower than the headlines suggest. Anyone running Ethereum app version 1.22.2 or later, verified through Ledger Live’s app manager, was never exposed to the specific buffer-desync path OneKey demonstrated. Anyone still running 1.22.1 or earlier should update immediately, both for this fix and for the two additional signing bugs closed in version 1.22.3 on August 27. Readers who have not reviewed their broader wallet hygiene recently may also want to work through a general crypto wallet security checklist, since host-side compromise, the precondition for this entire attack class, is usually the result of unrelated malware, phishing, or a compromised browser extension rather than anything specific to Ledger.
The episode is also a reminder that display verification habits matter more than most users treat them. A hardware wallet’s screen is only a meaningful defense if the owner actually reads every field before confirming, including the recipient address, amount, and any contract-call data. Attacks like this one exist specifically because most users glance at a transaction rather than scrutinize it. That same discipline applies whether someone is using a Ledger, a Trezor, a Coldcard, or a multisig setup built around a Safe wallet.
Market and Industry Impact
Ledger did not disclose any measurable drop in device sales or app downloads following the disclosure, and no source in this reporting cycle points to a stock-moving or funding-round reaction, since Ledger remains a private company. The more relevant market signal is reputational: OneKey used the incident as a marketing and positioning tool, leaning into its open-source narrative to draw a contrast with Ledger’s closed secure-element approach. That dynamic is likely to repeat. Hardware wallet vendors increasingly compete not just on price and chip specs but on demonstrated security research output, and a rival publishing a reproducible bug report functions as both a public service and a sales pitch.
For enterprise and institutional custody providers, the episode adds another data point to due-diligence checklists that already track supply-chain history, patch cadence, and update mechanisms across hardware wallet vendors. Firms building custody stacks on top of consumer hardware wallets, a common pattern for smaller funds and DAOs, will likely start asking vendors directly about buffer-and-display consistency checks, given that this exact bug class was previously undocumented as a named category before OneKey’s write-up.
Predictions: Where This Goes Next
Based on the pattern of vendor responses and the broader 2026 security news cycle, a few likely developments stand out.
- Expect other hardware wallet vendors, including Trezor and Keystone, to publish their own audits of buffer-and-display consistency in their signing apps within the next few months, prompted directly by OneKey’s disclosure.
- Expect Ledger to publicize its update-adoption metrics more aggressively, since the company’s strongest defense against this class of story is showing that most active users patch quickly.
- Expect competitor-vs-competitor security disclosures to become more common industry-wide, following the same playbook OneKey used, as wallet makers treat public vulnerability research as a growth lever rather than solely a liability.
- Expect renewed scrutiny of “blind signing” and complex contract-call transactions, since a race condition like this one would be far more dangerous on a transaction type a user cannot easily eyeball, such as a multi-step DeFi approval.
- Expect institutional custody auditors to start requesting formal, third-party-verified security attestations from hardware wallet vendors rather than relying on vendor self-reporting, given how much interpretation was required to separate “patched” from “hacked” in this single episode.
The Broader Lesson for Self-Custody
Self-custody advocates have spent years telling users to move funds off exchanges and onto hardware wallets precisely because exchange-side custody failures keep recurring. This episode does not undercut that advice, but it does complicate the simplified version of it. A hardware wallet shifts risk away from a custodian’s balance sheet and toward the integrity of the device, its firmware, and the host software a user connects it to. The Ledger transaction-replacement bug shows that the host-side half of that equation, meaning the browser, the dApp, and the computer, still carries meaningful attack surface even when the device itself has a certified secure element.
That is not an argument against hardware wallets. It is an argument for treating the entire signing pipeline, not just the chip, as the security boundary that matters. Vendors that build in state checks, like the one Ledger shipped in app 1.22.2, close specific gaps as they are found. But the September 2026 pattern, spanning a sidechain hack, a bridge exploit, a wallet-module flaw, and now a signing-app race condition, suggests the industry is still discovering new categories of this problem rather than running out of them.
Frequently Asked Questions
Was any Ledger user’s crypto actually stolen because of this bug?
No. Both Ledger and OneKey confirm the demonstration was a lab reproduction, and no source in this reporting identifies a real-world victim or confirmed fund loss tied to this specific flaw.
Which Ledger app version was affected?
The bug OneKey reproduced affected Ethereum app version 1.22.1 and earlier builds using Secure SDK versions up to 26.6.0. Ledger fixed the specific buffer-desync path in app version 1.22.2, released August 13, 2026.
Do I need to reflash my Ledger’s firmware to fix this?
No. The fix ships as an Ethereum app update distributed through Ledger Live, not a device firmware update. Users should open Ledger Live’s app manager and confirm they are running version 1.22.3 or later, since that version also closes two additional signing bugs Ledger disclosed on August 27.
What is a “transaction replacement attack” in plain terms?
It describes a scenario where a hardware wallet’s screen shows one transaction while the device actually signs a different one, because a malicious host sent a second command that overwrote the pending transaction data after the display had already rendered but before the user confirmed.
Does this affect Bitcoin transactions on Ledger devices, or only Ethereum?
Every source describing this incident scopes it specifically to Ledger’s Ethereum app and its signing flow. No reporting reviewed here documents an equivalent flaw in Ledger’s Bitcoin app.
Is OneKey’s device immune to the same type of bug?
No public, independently verified audit in the sources reviewed here confirms that OneKey’s own signing flow is immune to a comparable race condition. OneKey has emphasized its open-source firmware as an advantage for outside auditability, but that is a design philosophy claim, not a verified absence of similar bugs.
Why did Ledger dispute calling this a “hack”?
Ledger’s position is that a hack implies unauthorized access to a live, unpatched system with real victims, while OneKey’s test targeted an already-patched, outdated app version in a controlled lab environment with no user impact. Independent outlets reviewing Ledger’s version history corroborated that the fix predated OneKey’s public disclosure.
What should I check right now on my own hardware wallet?
Open your wallet vendor’s companion app, confirm you are running the latest firmware and coin-specific app versions, and review any pending transaction’s full details, including recipient address and contract-call data, before confirming on the physical device screen.
