[Security][tentative] Medium (correctness): Withdrawal Amount Endianness Mismatch Can Lock Requests

[evonide]

Context

Summit withdrawal requests originate from execution-layer calldata and are parsed by consensus logic before finalizer balance checks and queueing. The amount field must have one canonical byte order across documentation, helper tooling, and the production parser so validators and operators can request the intended withdrawal amount.

This finding concerns the handoff between the documented helper flow and consensus decoding. The normal flow is that the bytes submitted for a withdrawal amount should decode to the same numeric value that the operator intended.

Claim

Summit documentation and the withdrawal helper encode withdrawal amounts as big-endian uint64, but the consensus parser decodes the execution request amount as little-endian. Standard nonzero requests can therefore be parsed as much larger amounts and rejected as exceeding the validator balance.

A validator or operator following the documented withdrawal helper flow can submit a nonzero withdrawal amount whose bytes consensus parses as a different little-endian value. The trigger is normal authorized withdrawal operation, not an unauthenticated third-party attack.

Flow

The path is reachable for execution-layer withdrawal requests generated from Summit's documented big-endian calldata format and processed by the consensus execution request parser. The effect appears for non-palindromic nonzero amounts where big-endian and little-endian decoding differ; the claim is not that a malicious caller can redirect or over-withdraw another validator's funds.

Impact

A normal nonzero withdrawal encoded by Summit tooling can be interpreted as an enormous little-endian amount and skipped for insufficient balance. Validators following the documented flow can be unable to withdraw or exit until the format mismatch is corrected.

Root Cause

The docs/tooling and consensus parser disagree on byte order for the 8-byte withdrawal amount field.

Code

• The user-facing docs specify an 8-byte big-endian amount: https://github.com/SeismicSystems/summit/blob/ed2c5c8/docs/staking-and-participating.md#L36.
• The withdraw_and_exit helper also documents and constructs big-endian withdrawal calldata: https://github.com/SeismicSystems/summit/blob/ed2c5c8/node/src/bin/withdraw_and_exit.rs#L339.
• Consensus parsing extracts the last 8 bytes and decodes them with u64::from_le_bytes: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/execution_request.rs#L104.
• The finalizer rejects parsed withdrawal amounts larger than the account balance before queueing the request: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L1606.

Related Issues/PRs

Related issues cover adjacent withdrawal request parsing, queueing, and validator lifecycle edge cases.

• [Security][tentative] High (attackable): Genesis Can Configure a Zero Withdrawal Cap #224
• [Security][tentative] High (attackable): Invalid Deposit Refunds Can Starve the Withdrawal Queue #226
• [Security][tentative] High (attackable): Process-Time Deposit Refunds Can Merge Later Withdrawals Into a Stale Address #229
• [Security][tentative] High (correctness): Protocol Stake Bounds Can Become Empty #230
• [Security][tentative] High (attackable): WithdrawalQueue Deserialization Accepts Inconsistent Indexes #234
• [Security][tentative] Medium (attackable): Last-Block Withdrawal Can Be Dropped By Same-Block Deposit #248

Fix

• Use the byte order required by the execution request format consistently in docs, tooling, parser, and tests.
• Add fixture tests for representative calldata values such as 1 gwei, 32 ETH, and full-balance exit.
• Reject or migrate any incompatible legacy encoding explicitly.