Thursday, September 17, 2026

Creating liberating content

ECB opens merchant applications...

The European Central Bank has opened applications for online merchants to join a...

Bitcoin Price Wobbles Before...

Bitcoin’s price swung before settling largely unmoved over a 24-hour period...

Bitcoin miners have amassed...

Bitcoin miners have signed more than $100 billion in AI contracts while generating...

“The Fed Has Already...

Peter Schiff says the bond market didn’t break recently,...

Ledger patched an Ethereum app bug that could show one transaction and sign another

Ledger users should update the Ethereum app to version 1.22.2 after official code changes showed that a malicious dApp or other connected host could start a second signing command while a transaction was still under review.

In the path described by security company TestMachine, pressing approve could return a signature for substituted data instead of the transaction shown on the device.

TestMachine said on Aug. 22 that the attack required a dApp with WebHID access. The group said a second command could replace the transaction held in memory without opening a new review, leaving the original details on screen while the device signed the replacement.

It said the behavior was validated on Ledger Flex.

Ledger’s code history shows one official fix commit saying new signing commands could tear down an active review before returning an error. Another added state checks because approval callbacks previously signed without confirming that the app remained in the expected signing state.

Read More:  As Senate CLARITY Act odds plunge to 30%, Bitcoin’s refusal to drop signals a stealth upside trap

Version 1.22.2 closes that documented path by refusing a new signing session during an active review and rejecting an approval callback when the state no longer matches. The reviewed sources establish a code-level fix for those entry and callback defects.

Diagram showing the signing-state race described for Ledger’s Ethereum app and the safeguards added in version 1.22.2.

TestMachine asserted that shared code extended the issue to Nano X, Nano S Plus, Stax, and Apex, and the tagged app manifest lists those models alongside Flex as build targets.