Ledger Fixes Ethereum App Bug That Could Cause You to Sign a Different Transaction Than the One Shown
AI مارکیٹ کا خلاصہ
Ledger patched a vulnerability in its Ethereum app (fixed in v1.22.2) that could let a malicious web application exploit a race condition to swap transaction data after review, potentially turning benign actions into harmful approvals. While no private keys or firmware were compromised and no confirmed losses are reported, the incident highlights operational risk for Ethereum/ERC-20 users interacting with dApps via WebHID and may depress near-term risk appetite on ETH-linked activity.
اثر کی سطح
● درمیانہ
متاثرہ اثاثے
ETH/USDT-1.32%
AI تجزیاتی سمجھ · ETH/USDTAI تجزیاتی سمجھ
▼ Bearish
ابھی ٹریڈ کریں
⚠️ AI سے تیار کردہ تجزیاتی سمجھ خبروں کے مواد پر مبنی ہے اور صرف معلوماتی مقاصد کے لیے فراہم کی گئی ہے۔ یہ سرمایہ کاری کا مشورہ نہیں ہے اور نہ ہی BingX کے خیالات کی نمائندگی کرتی ہے۔ سرمایہ کاری میں رسک شامل ہے۔ براہ کرم ذمہ داری سے ٹریڈ کریں۔
Ledger users who hold Ether or ERC20 tokens should check the Ethereum app version installed on their device via Ledger Live. Versions earlier than 1.22.2 lack a security fix for a flaw that can break the core promise of a hardware wallet: that the device screen reliably reflects what you are about to sign.
The issue entered the public spotlight on August 24, 2026, when security firm TestMachine released its analysis. The patch was already in place by then, but Ledger and TestMachine dispute who discovered the bug first and when the fix was delivered. For users, the practical takeaway is simpler: confirm you are on Ethereum app 1.22.2 or higher, and review any token approvals you may have granted previously.
What the vulnerability affected
The device firmware and private-key custody were not compromised. The weakness was confined to Ledger's Ethereum app (the coin-specific app installed on the hardware wallet for ETH and ERC20 activity). In affected versions, the transaction review-and-sign flow could be disrupted so that the confirmation you provided applied to different data than what remained visible on the device display.
Researchers describe a scenario in which a malicious web application that already has access to the connected Ledger device can send a second signing command while the first transaction is still displayed for review. The app could then swap transaction data in memory without showing a fresh review screen. The display would still show the benign transaction you examined, but your approval would sign the substituted payload.
TestMachine reports reproducing the behavior on a Ledger Flex. Because multiple Ledger devices share Ethereum app code, Nano X, Nano S Plus, Stax and Apex are also treated as potentially affected. Ledger has not stated which version first introduced the bug; the public comparison in the research begins with version 1.22.1, which was tagged on May 27, 2026.
Why this matters: 'clear signing' is the security contract
Hardware wallets are meant to protect users even when the computer, browser, or website interface is compromised. The critical feature is clear signing: the wallet's own screen should show the real transaction details—recipient, amount, and for contract interactions, the specific action—before you confirm.
In this incident, the private key stayed on the device and firmware was unchanged, yet the user could end up authorizing something different from what they read. If the screen can no longer be treated as binding, that specific safeguard begins to resemble the risks of signing from a software wallet on an infected machine.
Technical root: race condition in APDU handling
The researchers attribute the flaw to a race condition, where outcomes depend on the ordering of near-simultaneous operations. Hardware wallets communicate with the host using APDU commands. Each signature involves multiple APDUs and an internal state that tracks which transaction is currently under review. In the flawed Ethereum app, that state could be overwritten while the on-screen review was still in progress, allowing a confirmation to apply to the wrong underlying transaction.
Why a website can talk to your Ledger: WebHID
The described attack relies on browser-level device connectivity. WebHID allows websites to communicate directly with connected USB devices after the user grants permission. This is how many decentralised applications interact with hardware wallets. The scenario is not a remote attack against an unplugged device; it requires that a user has already granted device access to a manipulated or compromised site and initiates a transaction there.
Why token approvals are the real risk
The highest-impact substitution is often not a transfer, but an approval. A token approval authorizes a smart contract to spend tokens later without further confirmations. Many dApps request unlimited approvals for convenience. These permissions do not expire and remain active until revoked.
A transfer typically limits loss to the amount shown and confirmed. An unlimited approval can, in the worst case, expose the full token balance at a time chosen by the approved contract's controller. This makes replacing a small transfer with a broad approval an especially attractive target.
Updating to Ethereum app 1.22.2 (via Ledger Live)
Version 1.22.2 addresses the issue with two safeguards: it blocks a new signing session while a review is underway, and it rejects confirmations if the internal state no longer matches what was shown.
Updating is done in Ledger Live: connect the device, open the app manager, and update the Ethereum app. Funds are not affected because keys are derived from the recovery phrase rather than stored in the app. Removing and reinstalling the app does not remove assets.
How to verify you are patched
In Ledger Live's device manager, check the Ethereum app version. If it is 1.22.2 or higher, the fix is present. If it is 1.22.1 or earlier, it is not. Checking the Ledger Live desktop/mobile version alone is insufficient.
Why firmware updates don't cover this
Firmware, Ledger Live, and individual coin apps are updated independently. Users may update firmware and assume everything is current while still running an outdated Ethereum app. In this case, an app update is the required remediation; there is no need to regenerate a recovery phrase.
Second step after updating: audit and revoke old approvals
The patch protects future signing, but it does not undo permissions already granted. Users who have interacted with dApps in recent months may want to review outstanding token approvals on their address using block explorers or dedicated approval-management tools. Approvals to contracts you no longer use can be revoked individually.
Revocations are on-chain transactions and incur network fees, so users may prefer to do cleanup during periods of lower gas costs. Revocations also appear in transaction history; keeping records can simplify later tax reporting, and many portfolio/tax tools can import these events automatically.
Disclosure dispute: Ledger vs TestMachine
Ledger and TestMachine provide conflicting timelines, reproduced here as their respective claims and not independently verified.
Ledger CTO Charles Guillemet said Ledger's internal security team (Ledger Donjon) discovered the issue and shipped a fix roughly two weeks before TestMachine's publication, with TestMachine approaching the bug bounty program afterward. He criticized TestMachine's messaging as fear-driven.
TestMachine says its automated system, Azimuth, found the weakness during testing on a Ledger Flex and that it shared results with Ledger. From TestMachine's perspective, no fix was available at the time it published.
Some verifiable dates sit between these narratives: the changelog for Ethereum app 1.22.2 is dated August 12, 2026, and the signed source tag August 13. The release reportedly only became visible publicly around August 24, coinciding with TestMachine's analysis. CryptoSlate assembled a technical reconstruction including these dates.
Have there been losses?
Based on information released by both parties so far, there is no confirmed case of the vulnerability being exploited. Private keys could not be extracted via this path.
The absence of confirmed victims comes with a caveat: a signature produced this way would look like any normal on-chain authorization. Users might only notice later when tokens move and could attribute losses to routine phishing. No confirmed cases does not prove none occurred.
What this says about hardware wallets and self-custody
This episode is not, by itself, an argument against hardware wallets. The attack required prior device access permission and a malicious application, it did not expose keys, and it has been patched. The broader lesson is operational: hardware-wallet security is not a one-time purchase outcome. It depends on ongoing maintenance across firmware, coin apps, and companion software, plus periodic hygiene such as pruning approvals and, for larger holdings, adding additional confirmation layers.
Practical checklist
1) Check your Ethereum app version in Ledger Live and update to 1.22.2 or higher. A firmware update alone is not sufficient.
2) Review and revoke unused token approvals on your addresses.
3) Document revocations and any resulting reallocations; they generate fees and appear in transaction histories, which matters for clean records and taxes.
(As of August 25, 2026. This article is not investment advice. Prices and fee structures change; verify current terms with the provider before purchasing.)