[Security][tentative] High (attackable): Invalid Deposit Refunds Can Starve the Withdrawal Queue #226

Context

Summit processes execution-layer deposit requests in the finalizer and may refund deposits that cannot be admitted as validators. Refunds and validator exits are both represented as withdrawal requests, and each epoch emits only a configured number of ready withdrawals.

The normal flow should keep rejected deposit traffic from consuming the same scarce withdrawal capacity needed for legitimate exits. Deposit admission limits and withdrawal emission limits are separate controls, so their interaction determines whether invalid deposits can create exit-queue pressure.

Claim

Deposits rejected after execution-request entry parsing can create refund withdrawals before deposit queue admission and outside max_deposits_per_epoch. Those refunds then share the same capped epoch withdrawal queue as validator exits, so many refundable invalid deposits can consume withdrawal slots mainly for gas and temporary lockup cost.

An execution-layer depositor can submit many parseable but invalid deposit requests with refund credentials, causing refund withdrawals to consume consensus withdrawal slots when they are emitted.

Flow

The path is reachable only for deposits that pass Summit's execution-request entry parser, including fixed-size deposit chunks and decodable Ed25519/BLS public keys, and still contain parseable withdrawal credentials when they reach the finalizer refund path. Fully malformed entries or malformed deposit public keys are dropped by parsing before refund construction. The attack requires enough invalid deposits to exceed available max_withdrawals_per_epoch capacity alongside honest withdrawal demand.

Impact

A low-cost stream of refundable invalid deposits can monopolize or heavily occupy the terminal-block withdrawal slots across many epochs. Honest validator exits, stake-bound withdrawals, and normal refunds can be delayed even though the attacker eventually receives their deposit amounts back. On chains with small withdrawal caps, this can turn deposit-contract spam into sustained validator-exit liveness pressure.

Root Cause

Rejected-deposit refunds are admitted directly into the shared withdrawal queue before valid-deposit admission accounting and without a separate refund budget or priority rule.

Code

• Rejected deposits with parseable withdrawal credentials create a WithdrawalRequest immediately: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L1539, https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L1573.
• Deposit refund reachability starts after the typed entry parser accepts a deposit entry and decodes each fixed-size deposit chunk; malformed entry length or invalid public-key encodings fail before finalizer refund construction: https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/execution_request.rs#L51-L57, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/execution_request.rs#L148-L192, https://github.com/SeismicSystems/summit/blob/ed2c5c8/types/src/execution_request.rs#L203-L211.
• The balance-range rejection happens before signature validation, so below-minimum or above-maximum deposits can reach the refund path without validator authorization: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L1951.
• Valid deposit processing is throttled later by max_deposits_per_epoch, but parse-time refunds bypass that admission loop: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L1728.
• Epoch aux data emits only max_withdrawals_per_epoch ready withdrawals, and overflow is rescheduled to the next epoch: https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L951, https://github.com/SeismicSystems/summit/blob/ed2c5c8/finalizer/src/actor.rs#L550.

Related Issues/PRs

Related issues cover adjacent withdrawal queue, deposit refund, validator top-up, and withdrawal parsing interactions that can disrupt request lifecycle handling.

• [Security][tentative] High (attackable): Genesis Can Configure a Zero Withdrawal Cap #224
• [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): Existing Validator Top-Ups Are Not Bound to Stored Consensus Key #244
• [Security][tentative] Medium (attackable): Last-Block Withdrawal Can Be Dropped By Same-Block Deposit #248
• [Security][tentative] Medium (correctness): Withdrawal Amount Endianness Mismatch Can Lock Requests #262

Fix

• Bound rejected-deposit refund creation with a separate per-epoch refund budget.
• Separate refund withdrawals from validator exits and define explicit priority for real exits.
• Apply deposit admission accounting before creating refund withdrawals.
• Prefer rejecting below-minimum or above-maximum deposits before they burn/lock funds in the EL deposit path.