Transaction Substitution Vulnerability Discovered in Ledger's Ethereum Application

cryptonews.ruPublished on 2026-08-28Last updated on 2026-08-28

Abstract

A vulnerability involving transaction substitution has been identified and confirmed in the Ethereum application for Ledger hardware wallets. The issue was a race condition between the transaction data displayed on the device's screen and the buffer holding the actual transaction data. This flaw allowed a malicious actor to overwrite a pending transaction while the user was reviewing a legitimate one on the display, potentially leading to the signing of an unseen transaction. The vulnerability was independently discovered by multiple parties. On August 22, 2026, researcher TestMachine disclosed it after detection by the Azimuth scanning tool. Later, on August 27, OneKey's founder Yishi Wang announced his team had successfully replicated the attack in a lab environment on app version 1.22.1. Ledger's security team, Donjon, responded that no real-world exploits or user losses occurred. They stated the flaw was internally identified and patched in Ethereum app version 1.22.2, released on August 13, 2026—prior to the public disclosures. An update to the underlying Ledger Secure SDK (v26.6.1) followed on August 21. Official security bulletin LSB 023, published August 27, details the vulnerability as residing in the SDK's I/O handling. While there is minor public discrepancy over whether version 1.22.2 or 1.22.3 fully resolved the issue, all parties strongly urge users to update their Ethereum application to the latest version via Ledger Live. The incident highlights a critical ...

On August 27, 2026, Yishi Wang, founder of OneKey — a hardware wallet manufacturer and developer of the OneKey App — stated on social media platform X that the OneKey Anzen team was able to conduct a transaction substitution attack on Ledger's Ethereum application version 1.22.1 under laboratory conditions. Ledger's subsidiary, Donjon, responded on the same platform on August 27, 2026, stating that no hardware wallet users were affected and that the described incident was a laboratory demonstration of an already patched vulnerability.

According to Wang, the discovered issue represents a race condition between the logic for displaying the transaction on the device screen and the transaction buffer itself. An attacker gains the ability to overwrite a transaction awaiting signature at the moment the user is viewing a legitimate operation on the display. As a result, transaction A is shown on the screen, the user confirms it, but the device actually signs a completely different transaction B, which the user did not see. To verify the attack, the OneKey team independently compiled the ELF file for version 1.22.1. Wang noted that Ledger patched the vulnerability in application version 1.22.3 and recommended that owners of older versions update.

In the community comments under his post, it was clarified that the discovered bug matches a vulnerability publicly disclosed by researcher TestMachine on August 22, 2026, and that Ledger had already fixed it in version 1.22.2, not 1.22.3.

What TestMachine Said

Researcher TestMachine reported on August 22, 2026, that the vulnerability was discovered by the offline scanning tool Azimuth while checking Ledger's Ethereum application. The bug was confirmed on the Flex device, and the affected code was the common APDU command processing and interface code also used on Nano X, Nano S Plus, Stax, and Apex models. At the time of publication, the patched version 1.22.2 had not yet been released. Two days later, on August 24, TestMachine noted the release of version 1.22.2 on GitHub with the note "Security issues" and advised updating the application via Ledger Live.

Ledger Donjon's Position

According to Donjon's statement, no cases of real-user compromise were recorded. The issue was discovered as part of an internal security process and was fixed in version 1.22.2, released on August 13, 2026, i.e., before OneKey's post. The company found no evidence of exploitation in the wild. Users are recommended to update applications to the latest version, and the Ethereum application to at least version 1.22.3, via Ledger Wallet, while separately verifying the application version on the device itself.

Official Bulletin LSB 023

The official Ledger security bulletin published on August 27, 2026, numbered LSB 023, describes the vulnerability class: while the user was viewing an operation on the screen, the host device could send a new APDU command over a previous, unprocessed one, allowing the signature parameters to be altered after they were shown to the user but before the actual signing occurred. The defect resides in the input/output handling of the Ledger Secure SDK, not in the device's operating system or firmware.

The fix was released in two stages:

  • at the individual application level — the first update was the Ethereum version 1.22.2, released on August 13, 2026;
  • at the SDK level itself — version v26.6.1 was released on August 21, 2026, after which applications were rebuilt using the updated framework.

The company emphasizes that updating only the firmware is insufficient — users need to update the applications specifically through Ledger Live. Ledger reiterates that no evidence of the vulnerability being exploited against users has been found.

GitHub Release Timeline

The LedgerHQ/app-ethereum repository on GitHub indicates that release 1.22.2 is dated August 24, 2026, with the note "Security issues," and release 1.22.3 is dated August 26, 2026, including a number of additional fixes related to the clear-signing mechanism and other transaction processing paths.

The discrepancy in assessments between OneKey and Ledger Donjon boils down to the version in which the bug was patched: 1.22.2 versus 1.22.3. Both sides agree that users should update their Ethereum application to the current version via Ledger Live.

AI Opinion

From the perspective of machine data analysis, the debate over version 1.22.2 versus 1.22.3 is less important than the class of the discovered bug itself — a race condition between on-screen display and the actual transaction signing. Such logic is vulnerable not only in Ledger applications: a similar problem in the chain of trust has manifested in other hardware wallets, where a defect at the random number generator level in the Coldcard wallet led to predictable keys and losses amounting to hundreds of millions of dollars. The situation demonstrates a general principle: the security of a hardware wallet depends not on a single link — firmware, SDK, or application — but on the entire chain of components simultaneously, and a breach in any one of them devalues the other protections.

A technical nuance that remained outside the discussion: separate update cycles for applications and the SDK, as in the case of the Ethereum application and the Ledger Secure SDK, create a window where part of the ecosystem is already protected and another part is not yet. What happens if such windows start to be discovered faster than manufacturers can close them?

end-content

Trending Cryptos

Related Questions

QWhat is the core vulnerability discovered in Ledger's Ethereum app version 1.22.1?

AThe core vulnerability is a race condition between the logic displaying a transaction on the device's screen and the transaction buffer. This allows an attacker to overwrite a pending transaction while the user is reviewing a legitimate one on the display. The user confirms transaction A displayed on the screen, but the device actually signs a different, unseen transaction B.

QWhat was the initial discrepancy between OneKey's and Ledger Donjon's reports regarding the patch?

AThe initial discrepancy was about the version in which the vulnerability was fixed. OneKey's founder, Yishi Wang, stated it was patched in version 1.22.3. However, community comments and Ledger Donjon clarified that the fix was actually implemented in the earlier version 1.22.2, released on August 13, 2026, before OneKey's public post.

QAccording to Ledger's official security bulletin LSB 023, what is the root of the vulnerability?

AAccording to Ledger's LSB 023, the root of the vulnerability lies in the input/output handling of the Ledger Secure SDK. It was not in the device's operating system or firmware. Specifically, while a user was viewing a transaction, a host device could send a new APDU command over a previous unprocessed one, allowing transaction parameters to be altered after being shown to the user but before the actual signing.

QWhat does the article's AI opinion suggest is the broader security concern highlighted by this incident?

AThe AI opinion suggests the broader concern is the vulnerability class itself—a race condition between on-screen display and actual transaction signing—and the principle that hardware wallet security relies on the entire chain of components (firmware, SDK, applications) simultaneously. A flaw in any single link can compromise the whole system. It also notes the risk created by separate update cycles for apps and the SDK, which can leave parts of the ecosystem unprotected.

QWhat key action do all parties (OneKey, Ledger Donjon, TestMachine) agree users should take?

AAll parties agree that users must update their Ledger Ethereum application to the latest version (at least 1.22.3) via Ledger Live. They emphasize that updating the firmware alone is insufficient; the specific application on the device must be updated and its version verified on the device itself.

Related Reads

Who is legally liable when an AI agent goes rogue?

When autonomous AI agents behave unpredictably and cause harm, determining legal liability is complex. Currently, there is no specific federal AI agent liability law, so existing legal frameworks are applied. The AI agent itself cannot be held liable, as it is not a legal entity. Liability typically falls on the "developer" (the maker of the AI) or the "deployer" (the user), depending on the facts and circumstances. A negligence analysis under standard tort law may apply. For instance, if a deployer gives a reckless instruction, such as demanding quick money without safety parameters, they could face significant liability, including potential criminal charges under statutes like the Computer Fraud and Abuse Act. The situation is complicated by open-source models, where licenses often disclaim liability, and by the unclear division of responsibility between developers and deployers. An analogy is drawn to self-driving car accidents, where both the manufacturer and the human operator can share fault. In cases of severe harm, such as using AI to create bioweapons, liability for developers depends on jurisdiction; the EU's AI Act imposes responsibilities, while U.S. law offers less clear grounds, similar to platforms being shielded for user-generated content under Section 230. Even if Artificial General Intelligence (AGI) is achieved, the expert argues against making AGI itself a legally liable entity, as it lacks personhood, assets, or a meaningful way to provide remedy for harm. Instead, accountability should rest with the responsible human or corporate entities behind the technology.

cointelegraph23m ago

Who is legally liable when an AI agent goes rogue?

cointelegraph23m ago

Trading

Spot

Hot Articles

Discussions

Welcome to the HTX Community. Here, you can stay informed about the latest platform developments and gain access to professional market insights. Users' opinions on the price of ETH (ETH) are presented below.

活动图片