Uppercase hexadecimal block bounds bypass the log-query range limit

[exromany]

Locations

• csm-widget/utilsApi/api/validation.ts:145-153

Summary

An unauthenticated caller can bypass the configured eth_getLogs range limit by using fromBlock: "0X0". The gateway forwards the query unchanged to providers that accept this hexadecimal spelling.

Root cause

ethGetLogsValidationFactory checks the range only when fromBlock.startsWith('0x') succeeds. Other strings, except earliest, skip the check entirely.

• Geth's block-number parser delegates numeric parsing to hexutil, which accepts both 0x and 0X prefixes.
• The current validator accepts 0X0 through 0x1312d00, a 20,000,000-block distance, while rejecting the equivalent lowercase request.

Impact

On a provider accepting Geth-compatible quantities, callers can request historical intervals exceeding the widget's one-million-block limit and consume upstream capacity outside its intended request budget. Repetition can temporarily degrade contract reads and transaction preparation or broadcasting through the shared gateway.

• Address restrictions and the 20-item batch limit remain enforced.
• The downstream response cap acts after upstream query execution begins; provider-specific limits may further constrain the impact.
• This is a low-severity availability issue with no direct on-chain state corruption.

Scenario

1. An attacker submits an allowed-chain eth_getLogs request targeting an allowlisted address, with fromBlock: "0X0" and toBlock: "0x1312d00".
2. Address validation succeeds, but the case-sensitive prefix check skips range validation.
3. The original filter reaches the selected provider, including after failover.
4. A compatible provider interprets the lower bound as block zero and evaluates the oversized interval. The attacker can repeat or batch these queries to consume shared capacity.

---

Drafted from LidoLens finding CSMW-RPC-LOGS-02