Ledger Patched a Clear-Signing Flaw, Then Stayed Quiet

Ledger quietly fixed a race condition in the clear-signing feature of its Ethereum app on August 12, 2026, and said nothing about it publicly. Ten days later a security firm found the same class of bug on its own, disclosed it, and now the two sides are arguing about what responsible disclosure is even supposed to look like.

• Ledger shipped Ethereum app version 1.22.2 on August 12, 2026, fixing a clear-signing race condition with no advisory, blog post, or public statement attached.
• The bug let a malicious dApp fire a competing APDU command while a user was reviewing a transaction, so the device screen could show one transaction while a different one was actually being prepared for signing.
• Private keys were never exposed. This was a display and timing flaw, not a key-extraction vulnerability.
• Security firm TestMachine independently found and publicly disclosed the same issue August 21-23 using an AI research agent called Azimuth, then reported it to Ledger's bug bounty program only after the fix had already been live for two weeks.

What Ledger actually patched on August 12

On August 12, 2026, Ledger pushed version 1.22.2 of its Ethereum app through the normal Ledger Live update channel. The release notes didn't flag a security fix, and there was no advisory, no blog post, no mention through any of Ledger's usual disclosure channels. Inside that update was a fix for a race condition in how the device processes APDU commands, the low-level instructions a connected computer sends telling the hardware wallet what to display and what to sign. The flaw sat specifically in clear-signing, the feature Ledger has built its entire security pitch around: what you see on the device's own screen is supposed to be exactly what gets signed, no matter what's happening on the computer it's plugged into.

RelatedvCenter's 9.8 Flaw Was Exploited Five Days After Disclosure

How does clear-signing normally work, and how did this flaw break it?

Clear-signing exists because blind-signing is dangerous. Older hardware wallet flows showed a wall of raw hex data and asked you to approve it, which meant trusting whatever your computer told you that data represented. If malware had compromised the machine, it could swap in a different destination address or a different amount and you'd have no way to catch it from the device screen. Clear-signing was Ledger's fix: the device itself decodes the transaction, the amount, the destination, the smart-contract function being invoked, and renders it on its own trusted display before you press confirm.

The race condition undermined the timing assumption that guarantee depends on. Because the flaw lived in how the device handled APDU commands arriving while a transaction was already under review, a malicious dApp could fire a second, competing command inside that window. The screen could keep showing the transaction you thought you were approving while the signing engine had already moved on to a different one, potentially something like an unlimited token approval routed to an attacker's address. You'd press confirm on what your eyes told you was safe and sign something else entirely.

Who was at risk, and how bad could it have gotten?

Anyone running an Ethereum app older than 1.22.2 on a Ledger device was theoretically exposed for as long as they hadn't updated, stretching back to whenever the underlying bug was actually introduced. That's not a small population. Ledger is the best-selling hardware wallet brand, and Ethereum is the chain most dApps are built against. The mitigating factor is that exploitation required a malicious or compromised dApp interface acting at the exact moment a user was reviewing a transaction. It wasn't a passive leak sitting there waiting to be scraped. As of August 24, 2026, nobody, not Ledger, not TestMachine, not any independent researcher, has confirmed a single case of funds actually stolen through this specific bug.

Why did Ledger stay silent for ten days?

Ledger's answer, delivered by CTO Charles Guillemet on August 23, is that its own Donjon security research team found the issue internally, using AI tooling of its own, and fixed it before anyone outside the company knew it existed. In that framing, silence isn't negligence, it's standard practice: patch first, and only disclose in detail if there's a reason to believe attackers already know. Plenty of security teams operate this way, on the theory that a public writeup of a fixed bug still hands a roadmap to anyone who hasn't updated yet.

The trouble is that "we fixed it quietly" looks identical to "we're hoping nobody notices" until someone outside the company forces the question. TestMachine forced it. Guillemet called their public framing an attempt at "manufacturing fear for attention," arguing it implied the flaw was still live when it had actually been resolved for roughly ten days already. That's a fair complaint about how the disclosure read. It doesn't erase the fact that Ledger's own silence is what left the gap for a competing narrative to fill in the first place.

RelatedCopilot Explained Its Own Guardrails, Then Leaked Them

What should Ledger users do right now?

The fix is already live, which makes this one of the easier vulnerabilities to close out. Open Ledger Live, confirm the Ethereum app installed on your device reads version 1.22.2 or later, and update if it doesn't. That's the whole remediation. There's no key rotation required and no need to move funds to a new wallet, since private keys were never extractable through this flaw. If you sign Ethereum transactions on a Ledger regularly, especially through third-party dApp interfaces, this is a two-minute check worth doing today rather than assuming some earlier update already covered it.

1. Aug 12Ledger ships Ethereum app 1.22.2 fix included, no advisory published
2. Aug 21-23TestMachine discloses the flaw publicly used an AI agent, "Azimuth," to find it
3. Aug 23Ledger CTO responds says it was fixed two weeks earlier internally

Our take

The interesting fight here isn't really about whether the bug was dangerous. Both sides agree it's fixed, and nobody has proven a loss. It's about what responsible disclosure means when the party doing the disclosing found the same bug independently and has no way to verify the vendor's private timeline. TestMachine's public framing did make the flaw sound like an open wound. Ledger's ten days of silence are what created the conditions for that framing to land in the first place.

A company that wants credit for quiet, competent security work has to actually say something when it patches a trust-critical feature, even a short note, or it forfeits the benefit of the doubt the next time a researcher shows up with a discovery of their own. Clear-signing was Ledger's answer to the question of how you trust hardware over a compromised computer. A timing bug in that exact feature, whoever found it first, is the kind of thing users deserve to hear about from the vendor directly, not read about later in a rival's press cycle.

Original analysis by GenZTech. Source: The Cyber Express