Ledger Security Bulletin 025

27 August 2026: During a swap, a token approval carrying the expected address and quantity passed the app’s checks and was signed without being shown to the user.

Summary

A vulnerability was identified in the Ethereum app for Ledger devices, in the path used to sign a token payment on behalf of the Exchange application during a swap. That path verified the address and the quantity carried by the transaction, but not the nature of the operation being requested. A token approval carrying the expected address and quantity therefore passed the checks and was signed without being displayed, granting a spending permission instead of making the payment the user had accepted.

The vulnerability was identified by Ledger’s internal automated security review of the application and is fixed in Ethereum app version 1.22.3.

Description

When a user performs a swap, the operation is reviewed and accepted in the Exchange application: the asset, the quantity, and the address the funds are to be sent to. The Ethereum app is then called to sign the corresponding token payment. Because the user has already accepted the operation, the app does not ask again. It signs automatically, after checking that the transaction it has been handed matches what was accepted.

Those checks covered the address and the quantity, but not the nature of the operation. Sending tokens and granting permission to spend them are two different operations that carry the same two pieces of information, an address and a quantity, in the same order. An approval carrying the expected address and quantity was therefore indistinguishable from the expected payment. It passed the checks and was signed with no screen shown to the user.

The consent given in the Exchange application was for a payment of a stated quantity to a stated address. What could be signed instead was a standing permission for that address to take the same quantity at a later time. The same path also tolerated additional data appended to the call, which an ordinary token payment never carries.

Impact

Exploitation requires control of the transaction submitted to the device during a swap: a hostile or compromised swap provider, or malware placed between the Exchange application and the signer. Where that condition holds, the user believes they are paying a fixed quantity of tokens to complete a swap, while the signed transaction instead grants a standing permission over that quantity, and the device displayed nothing that would let them notice the difference.

Several properties of the swap flow limit what can be obtained this way.

The beneficiary is not chosen by the attacker. The address that receives the permission has to be exactly the deposit address the Exchange application validated for that swap, so the only party able to use the permission is the swap provider itself. Malware on the host cannot redirect it to an address of its own. It can only cause the user to grant it to the provider they were already paying.

The quantity is not chosen by the attacker either. It has to match the quantity and the asset the user has already accepted, so the permission cannot exceed what the user was in the process of sending to that same address. There is no path to an unlimited permission, nor to a different asset.

Nothing moves on its own. A permission transfers no funds by itself. Taking the tokens requires a second, separate transaction sent later by the deposit address, which is public and which the user can pre-empt by revoking the permission.

The anomaly surfaces quickly. Because no payment ever arrives, the swap does not complete and the provider delivers nothing in return, so the user is left with a failed operation and an approval where a payment was expected, rather than a silent loss.

Outside the swap flow the issue does not arise, since an approval is displayed and confirmed by the user like any other operation. The realistic worst case is therefore that a hostile or compromised swap partner obtains, in a deferred and revocable form, the same quantity of the same asset that the user had already agreed to send it, and delivers nothing in exchange. That remains a real loss of funds and a real break of the rule that the device signs only what the user accepted, but it is confined to a single swap in progress and cannot be turned into a permission of arbitrary size in favour of an arbitrary address.

Ledger has no evidence that this issue was exploited against users.

Affected releases

Ethereum app versions 1.20.0, the release in which the current swap validation path was introduced, through 1.22.2.

Remediation

The swap path now confirms that the operation being signed really is a token payment, and rejects any additional data appended to the call, before the address and the quantity are compared and before the transaction can be treated as accepted. The correction is released in Ethereum app 1.22.3.

Users should install Ethereum app 1.22.3 or later and verify the application version on the signer. Updating device firmware alone does not establish that the affected application has been replaced.

Credit

Identified by Ledger’s internal automated security review of the Ethereum app, which detected the missing check, confirmed the behaviour on a test build, and proposed the correction that was released.

Ledger thanks the security researchers who continue to report findings against its applications through the Ledger Devices Bug Bounty programme.

Timeline

Date	Action
28 April 2026	Ledger’s internal automated review identifies the missing check.
25 May 2026	The correction is merged.
25 August 2026	Ledger publishes Ethereum app 1.22.3 containing the correction.
27 August 2026	Security bulletin published.