EUVD-2026-46400
GHSA-6552-m3hr-mqwj
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attacker must control chunk streaming via malicious dApp (AC:H); victim must confirm on physical device (UI:R); transaction integrity fully compromised but no confidentiality or availability impact (I:H, C:N, A:N).
Primary rating from Vendor (cisa-cg).
CVSS VectorVendor: cisa-cg
Lifecycle Timeline
3DescriptionCVE.org
Trezor Safe 3, Safe 5, and Safe 7 firmware contains a confirmation-binding flaw in the Ethereum sign_tx / sign_tx_eip1559 flow. For contract interactions, the device confirms only the initial calldata chunk while the signature commits to the full streamed calldata. An attacker could present calldata to a victim then supply a different tail that changes the signed transaction. Fixed in 70c9b0c.
AnalysisAI
Ethereum transaction signing on Trezor Safe 3, Safe 5, and Safe 7 hardware wallets can be silently subverted because the device displays and requests on-screen confirmation only for the initial calldata chunk but cryptographically commits the entire streamed calldata into the final signature. A malicious dApp operator or man-in-the-middle attacker can present a benign-looking initial chunk for the victim to approve on the physical device, then stream a manipulated calldata tail that alters the actual transaction semantics - for example changing a token-approval recipient, amount, or contract target. No public exploit has been identified at time of analysis, and the flaw is fixed in upstream commit 70c9b0c per the vendor's firmware repository.
Technical ContextAI
The flaw resides in the Ethereum sign_tx and sign_tx_eip1559 flows in Trezor firmware (CPE: cpe:2.3:a:trezor:safe_3:*:*:*:*:*:*:*:*, cpe:2.3:a:trezor:safe_5:*:*:*:*:*:*:*:*, cpe:2.3:a:trezor:safe_7:*:*:*:*:*:*:*:*). Ethereum contract calldata can be arbitrarily large and is therefore delivered to the device in multiple sequential chunks. The original firmware called require_confirm_other_data() only for the initial chunk, then consumed subsequent chunks directly into the RLP/SHA digest without displaying them. CWE-358 (Improperly Implemented Security Check for Standard) accurately captures the root cause: the on-device confirmation step was structurally decoupled from the iterative digest computation, so the data a user explicitly approved and the data actually committed to by the private-key signature were not bound to the same byte stream. The fix in commit 70c9b0c introduces a make_confirm_data() function that invokes confirm_blob_prefix() on every chunk as it is fed into the digest, enforcing a cryptographically consistent binding between displayed and signed data.
RemediationAI
The primary fix is to update Trezor Safe 3, Safe 5, and Safe 7 firmware to a version that incorporates commit 70c9b0c07748 or later. The exact patched firmware release version number is not independently confirmed from the available data - users should consult the official Trezor firmware changelog alongside the upstream patch at https://github.com/trezor/trezor-firmware/commit/70c9b0c07748 to identify the correct release. As a compensating control before patching, users should avoid signing Ethereum contract transactions with large or multi-chunk calldata through any dApp that is not fully trusted and locally verified, since the device cannot currently be relied upon to display the complete transaction data. Restricting Ethereum signing to simple value transfers (no calldata) eliminates exposure entirely but may be operationally impractical. These workarounds require sustained user diligence and do not remediate the underlying firmware flaw.
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today