Thursday, September 17, 2026

Creating liberating content

Circle opens Arc mainnet...

Circle has scheduled the public launch of Arc for Sept. 16, giving USDC...

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...

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:  After MiCA deadline, majority of Binance users sent funds to self-custody not other compliant exchanges

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.