AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
High 72 Bitcoin

fix(core): confirm Ethereum data during its hashing

Public commit record

What the developer wrote

Authored by Roman Zeyde

77/100 · Adequate
fix(core): confirm Ethereum data during its hashing

(cherry picked from commit 09ab831c4eaced4e1702dd74cc6713e0b0f5975d)
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides an explanatory body
The short version

What changed, and why it matters

This update changes how Trezor hardware wallets confirm Ethereum transaction data. Previously, the device asked the user to approve the entire data payload before it began hashing the transaction. Now, it confirms data piece by piece while the transaction is being hashed, and only shows the final transaction summary right before signing. The change is marked as a security fix in the project's changelog, suggesting the old behavior could let a user approve data that does not match what is actually signed.

Recommended action

Treat this as a security fix and include it in release notes. Users should upgrade firmware. Developers should verify that the new `confirm_blob_prefix` flow correctly handles very large data payloads and that cancellation at any chunk aborts signing. Review whether the legacy (Trezor One) code path has a corresponding fix, since this patch only touches core/ code.

Security signals we found

01

Changelog entry explicitly labeled `.security`: 'Confirm all data during Ethereum transaction hashing.'

02

UI confirmation order changed from 'confirm all data, then hash' to 'hash and confirm chunks together, then confirm summary, then sign'.

03

New `confirm_blob_prefix` UI primitive confirms only a prefix of each chunk and tracks `confirmed_len` across chunks.

04

Old `require_confirm_other_data()` removed; data confirmation is now tied to the streaming hash loop.

05

Tests updated to expect additional ButtonRequest prompts during data streaming on non-legacy models.

Risk score

Why this scored 72/100

Our methodology →
Potential impact 22/30
Exploitability 16/25
Stealth signal 10/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.