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

fix(core): hardening ETH unstake and claim

TZ72414778 View source ↗
Public commit record

What the developer wrote

Authored by obrusvit

92/100 · Strong
fix(core): hardening ETH unstake and claim

- unlike stake, the value of unstake and claim is supplied as a contract
arg. Even though the contracts are non-payable, we must enforce
`msg.value` to be 0
- in addition, enforce the right chain_id to prevent replay attacks

(cherry picked from commit 31323e62fbae7bb7b9ccc17a236e97cd8efeb91a)
✓ Descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This update tightens the rules for two Ethereum staking operations—unstake and claim—on Trezor hardware wallets. Before the fix, the device did not verify that the user was on the correct Ethereum network (chain ID) and did not block ETH from being attached to unstake/claim transactions. Because those contract functions reject incoming ETH, any ETH sent with them would normally be lost. The patch now rejects such transactions before they can be signed, preventing accidental or malicious loss of funds and cross-chain replay attacks.

Recommended action

Treat this as a security fix and include it in the next firmware release. Users should upgrade once available. Wallet software interacting with Trezor should ensure it does not construct unstake/claim transactions with non-zero value or wrong chain_id, as the device will now reject them.

Security signals we found

01

Validation bypass: address-only matching allowed staking-specific UI/approval logic to trigger on the wrong chain

02

Replay-attack vector: missing chain_id binding could let a staking transaction be replayed on another supported network

03

Fund-loss vector: non-payable unstake/claim calls accepted msg.value, which would be trapped by the contract

04

Negative test coverage added for value and trailing-data cases

05

Changelog entry explicitly labels the change as security-relevant

Risk score

Why this scored 74/100

Our methodology →
Potential impact 22/30
Exploitability 16/25
Stealth signal 10/15
Affected reach 12/15
Confidence 9/10
Evidence quality 5/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.

More from Trezor firmware

Related watches

Informational 15 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

chore(core): improvements to English copy

This commit is a routine text cleanup for the Trezor hardware wallet's on-screen English messages. It fixes punctuation, removes unnecessary line breaks, and makes small wording tweaks (for example, changing 'PIN will be required' to 'A PI…

1dbc2c3cby Michal Kazda+22−422 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 59 AI analysisMessage 57 · Thin
TZ TrezorTrezor firmware BitcoinHardware wallets

feat(core): app root packet downgrade protection

This commit adds downgrade protection for a new 'app root packet' system in Trezor firmware. Previously, the code had a TODO note saying downgrade protection needed to be considered. The change makes the device remember the timestamps of p…

Replaces a TODO comment ('!@# TODO: Consider downgrade protection') with concrete timestamp-based anti-downgrade checksAdds per-ring timestamp state to prevent rollback of root-of-trust packetsAdds chain_timestamp field and 90-day drift bound to root packet format
4a9cf168by cepetr+335−3112 files
No security note in commit
Open full analysis →Source commit ↗
Moderate 67 AI analysisMessage 62 · Adequate
TZ TrezorTrezor firmware BitcoinHardware wallets

fix(core/rust): discard low-order keys in THP handshake

This commit fixes a cryptographic edge case in Trezor's THP (Trezor Host Protocol) handshake. It now rejects Curve25519 public keys that are all zeros or that produce an all-zero shared secret. A zero public key can cause the Diffie-Hellma…

Curve25519 zero/low-order public key rejection added to DHZero shared-secret output rejected after scalar multiplicationHandshake state machine now transitions to Failed on initiation-response error
429a283dby M1nd3r+45−74 files
No security note in commit
Open full analysis →Source commit ↗