violation of EIP-6110 in types.DepositLogToRequest iaccepts any 576-byte payload (no ABI offset/length validation) lead to potential EIP-7685 requestsHash divergence

[sko94]

System information

Geth version: geth version
CL client & version: e.g. lighthouse/nimbus/prysm@v1.0.0
OS & Version: Windows/Linux/OSX
Commit hash : (if develop)

Expected behaviour

the core.ParseDepositLogs should only include ABI-valid deposit events in the EIP-7685 requests list.
and the types.DepositLogToRequest should verify the deposit event’s ABI head offsets and dynamic lengths (for bytes,bytes,bytes,bytes,bytes) before slicing:

• head offsets: 160, 256, 320, 384, 512
• lengths: 48, 32, 8, 96, 8
  with full bounds checks.

Actual behaviour

the types.DepositLogToRequest only checks len(data) == 576, then copies fixed slices using hard-coded increments.

It does not validate the 5 head offsets or the 5 length words.

so Any 576-byte payload (with the correct topic/address filter at the call site) is treated as a valid deposit, which can change the derived EIP-7685 requestsHash compared to a stricter client that enforces the ABI.

• Note: This is not exploitable on Ethereum mainnet because is alerdy talk to the teams about this and this say to open a issue here, the mainnet not affected because logs come only from the canonical deposit contract. It is, however, a spec-compliance gap and a potential cross-client divergence for other chains/configs or future stricter decoders.

Steps to reproduce the behaviour

here is the Vulnerable call chain:

in the --->

go-ethereum/core/state_processor.go

Line 322 in 8ce2047

request, err := types.DepositLogToRequest(log.Data)

https://github.com/ethereum/go-ethereum/blob/8ce204734879580a0a38e13708c8f473967eac83/core/types/deposit.go#L27C1-L32C1

• here in the core/state_processor.go: ParseDepositLogs(&requests, allLogs, cfg) --> types.DepositLogToRequest(log.Data)
• here in the core/types/deposit.go: only checks len(data)==576, then slices fixed positions (no ABI validation)

Impact

So With EIP-7685, the deposits contribute to the header’s requestsHash.
A lenient vs strict decoder can derive different requestsHash for the same block if the deposit payload is malformed (relevant for non-mainnet chains/configs that point DepositContractAddress elsewhere, devnets, forks, or future stricter clients).

Backtrace

here is a proposed fix

In types.DepositLogToRequest:

• need to Keep len(data) == 576 check.
• and need to Read the 5 head offsets (first 5 words); require exactly 160/256/320/384/512 and in-bounds.
• At each head, read the 32-byte length; require 48/32/8/96/8 and in-bounds.
• Bounds-check all slices; parse amount/index (8 bytes) as per the spec.
• Return error on any mismatch.
  (Defense-in-depth in ParseDepositLogs: optionally require len(log.Topics) == 1 in addition to topic0 == depositTopic, since the deposit receipt is a single-topic event.)

Backtrace

N/A (logic issue; reproducible via unit test)

[fjl]

There was a PR for this: #32669

But we closed it. Essentially, we think that the additional validation is not required. We already check the topic of logs, and we know what the contract looks like. So on mainnet, no wrong events can ever be emitted by the contract. Furthermore, it is very unlikely for the contract to emit a log with the correct topic and a matching event data size.

[sko94]

Totally understood. You’re right: on Ethereum mainnet the address+topic filter confines the parsing to the canonical, immutable deposit contract, so this isn’t a live mainnet exploit. But The issue is not source spoofing it’s decoder correctness. Today the use of types.DepositLogToRequest treats “len(data) == 576” as sufficient and doesn’t validate the ABI head offsets (160/256/320/384/512) or the lengths (48/32/8/96/8). That means two honest clients—one lenient (Geth today) and one strict (spec-aligned), can derive different EIP-7685 requestsHash from the same deposit log in non-mainnet deployments (alt-nets, testnets, forks, misconfigs) or mixed-client environments. A one-liner shows the leniency: DepositLogToRequest(make([]byte, 576)) succeeds. This is a spec-compliance hardening request with zero behavioral change on mainnet (the canonical contract already emits ABI-valid data) and negligible cost. I think a minimal patch: in DepositLogToRequest, need to verify the 5 offsets and 5 lengths (bounds-check) before slicing; or require len(log.Topics) == 1 at the call site. It removes an unnecessary assumption about the producer and guarantees the cross-client requestsHash consistency wherever this path is enabled. I’m happy to open a tiny PR with the checks and a unit test. Message ID: ***@***.***>

…