Security · Disclosure
Two Machines Found the Same Bug. Then the Humans Started Arguing
Ledger's in-house AI found a transaction-swapping race condition in its Ethereum app and shipped a silent fix. Ten days later, another company's autonomous agent found the same flaw and published it. The fight that followed is about who gets to speak.
On Aug 12, Ledger shipped version 1.22.2 of its Ethereum app. The release notes did not say that it closed a flaw which could have let a malicious website swap the transaction on your screen for a different one, while you were looking at it. There was no security advisory, no blog post, no disclosure. The patch went out and the company said nothing, per Crypto Briefing.
Ten days later a security firm called TestMachine published the bug anyway. What makes this more than a routine disclosure spat is how both parties found it. Ledger's in-house research group, Donjon, identified the flaw using what CTO Charles Guillemet described as the team's AI-powered vulnerability research system. TestMachine found it with an autonomous agent it calls Azimuth, during an unattended scan. Two machines, working for opposed interests, converged on the same defect in the same device inside the same month.
What the bug actually did
The flaw was an APDU command race condition — APDU being the low-level message format a host computer uses to talk to a smart-card-style secure element. Ledger's "clear signing" flow is supposed to render a human-readable summary of a transaction on the device's own screen, so that what you approve with a physical button press is what you actually sign. It is the feature that exists specifically to end blind signing.
The race broke that guarantee. A malicious decentralized application with the right access could fire competing commands at the device while a review was already open on screen. The transaction data held in memory for signing could be replaced without the display refreshing to match. In practice, as reported, a user could believe they were approving a modest token transfer while in fact authorizing unlimited token approvals to an attacker's address. The screen said one thing; the secure element signed another.
Version 1.22.2 closes it by refusing a competing signing command while a review is in progress. No funds have been reported lost to the flaw.
Ten days of silence, then a public argument
| Date | Event | Public advisory? |
|---|---|---|
| Aug 12 | Ethereum app 1.22.2 ships with the fix | None |
| Aug 21–23 | TestMachine publishes the race condition | By the researcher |
| Aug 23 | Guillemet responds publicly, disputing the framing | Statement, not advisory |
The dispute, and what each side claims
Guillemet's position is that users on the current version were already protected, that the fix had shipped roughly two weeks before the public notice, and that presenting the flaw as live was, in his framing, manufacturing fear for attention. On the narrow technical point he is right: a patched device was not exposed.
The two accounts diverge on process, and the divergence is not reconcilable from the outside. Guillemet says TestMachine approached Ledger's bounty programme only after the fix had already shipped, and did not discuss the finding with the bounty team before publishing. TestMachine says it shared and verified the finding with Ledger — and declined any bounty. Both cannot be fully accurate. Neither has published a timestamped record that would settle it.
TestMachine also claims a wider device footprint than has been demonstrated: it says it validated the issue on Ledger Flex and lists Nano X, Nano S Plus, Stax and Apex as affected, though no complete proof of concept showing fund theft across that range has been made public. Its Azimuth agent is credited with catching 86.3% of known bugs at roughly 2.7% false positives — on EVMBench, a benchmark TestMachine itself publishes. Self-graded exam, self-reported score. Take it as a claim, not a measurement.
Tagged on the 13th, visible rather later
Added Sep 9, 2026. Ledger's defence rests entirely on a date: the fix shipped Aug 12, therefore anyone current was safe. That date turns out to describe the code, not the release.
Per CryptoSlate, the changelog entry for 1.22.2 carries Aug 12 and the signed tag in the source repository is dated Aug 13. But a signed tag is not a published release, and TestMachine reported on Aug 22 — ten days after the changelog date — that the fix was still not released. CryptoSlate does not pin down the exact moment the GitHub release became publicly visible, saying only that it happened somewhere between Aug 13 and Aug 22.
That gap matters more than it sounds. The whole force of "users were already protected" depends on the fix being installable by ordinary owners through Ledger Live, not merely committed and tagged in a repository. If the release sat unpublished for some part of those ten days, then for that window the flaw was fixed in Ledger's source tree and live on Ledger's customers' devices simultaneously. Nobody has published the timestamps that would resolve exactly how long that window was, and Ledger has not been asked to on the record.
TestMachine has also said the eventual GitHub release notes read, in their entirety, "Security issues." This desk has not independently verified the body text, and TestMachine is an interested party in the dispute — but if accurate, it is a striking artifact: two words standing in for the disclosure Ledger declined to write.
The device list was in the manifest
One claim in the original dispute deserves refining. TestMachine's list of affected hardware — Flex, Nano X, Nano S Plus, Stax and Apex — was initially read, including by this desk, as an assertion running ahead of its evidence, since the firm demonstrated the issue on a Flex alone.
CryptoSlate's reading of the tagged app manifest complicates that. Those five devices are listed in the manifest itself as build targets for the affected app version. That does not prove the race is exploitable end-to-end on each one, and no complete proof of concept showing fund theft across the range has been published. But the device list was never purely TestMachine's inference; it is what Ledger's own build configuration says the vulnerable code was compiled for. The burden of narrowing that list sits with the vendor, not the researcher.
On the publication date itself, accounts still vary: outlets place TestMachine's disclosure between Aug 22 and Aug 24, and no party has published a definitive timestamp.
Why the silent patch is the real story
Strip out the personalities and a genuine question remains: when a vendor's own AI finds a flaw and the vendor fixes it quietly, has anyone been wronged?
Ledger's implicit answer is no — the fix shipped, users updated, disclosure would only have armed attackers during the rollout window. That argument has real weight, and it is the same logic behind every coordinated embargo, including the one Core Lightning is running right now. But embargoes end with publication. Ledger's silence had no announced end. Without an advisory, a user has no way to know that 1.22.2 is a security release rather than a routine update, and hardware wallet owners are famously slow to update firmware they have no stated reason to touch. A patch nobody knows to install is a patch that protects the people who happened to be current.
There is also the awkward fact that this is the second time in a month that hardware wallet buyers have had to reassess what their device guarantees, after the $116 million Coldcard exploit. Clear signing was the answer to blind signing. A race condition in clear signing is not a small footnote — it is a crack in the specific promise that justifies the hardware.
The Take
The interesting party here is neither company. It is the fact that two independent AI systems, one defending and one probing, found the same non-obvious flaw in the same device within days of each other. That symmetry is the actual news, and it prices the disclosure debate for the rest of the decade: if your in-house agent found it, assume somebody else's agent is about to. Under those conditions a silent patch is not a safety measure, it is a bet that your machine was faster than theirs — and Ledger only won this round by ten days. Ship the fix quietly if you must. But publish the advisory, because the countdown to independent rediscovery is now measured in days, and your users are the ones who need to know the clock is running.