Reproduced Exploit

Payable delegatecall loop reuses `msg.value` — value-accounting hazard

Every delegatecall in a payable batch inherits the original msg.value. The reduction calls a hypothetical value-sensitive credit() twice and records two ether of credit from one ether supplied.

Jun 2021Ethereumdependency2 min read

Loss

Future value-sensitive logic can count one payment multiple times

Chain

Ethereum

Category

dependency

Date

Jun 2021

Source

AuditVault

EVM Playground

Source-level debugger — step opcodes and Solidity in sync

evm-hack-analyzer

The attack is replayed in an in-browser EVM preloaded with the exact dumped fork state. The execution tree shows every call; step by Solidity line or by opcode across all depths — source, Stack, Memory, Storage, Balances (native / ERC-20 / NFT), Transient storage and Return value stay in sync. Click a tree node, opcode, or source line to jump. No backend, no live RPC.

Loading fork state…

Source & credit. Reproduction of a public audit finding curated by AuditVault — the original finding: 16976-use-of-delegatecall-in-a-payable-function-inside-a-loop-trai. Standalone Foundry PoC and full write-up: 16976-use-of-delegatecall-in-a-payable-function-inside-a-loop-trai_exp in the evm-hack-registry mirror.


Vulnerability classes: vuln/dependency/unsafe-external-call · vuln/logic/state-update

Reproduction: self-contained synthetic Foundry reduction; see output.txt.

Key info#

FieldValue
LossFuture value-sensitive logic can count one payment multiple times
Vulnerable contractLadle.batch
Attacker EOA0x1111111111111111111111111111111111111111
Attack contractLadle via Exploit
Attack txExploit.run{value: 1 ether}()
Chain / block / dateEthereum model · block 0 · 2021-06
Compilersolc 0.8.24 (synthetic)
Bug classPayable delegatecall loop retains original value

TL;DR#

Every delegatecall in a payable batch inherits the original msg.value. The reduction calls a hypothetical value-sensitive credit() twice and records two ether of credit from one ether supplied.

Background#

Yield V2 did not use msg.value meaningfully at review time, but a later refactor could turn this into an accounting exploit. The PoC makes that future-use hazard explicit.

The vulnerable code#

SOLIDITY
for (uint256 i; i < calls.length; ++i) {
    (bool success,) = address(this).delegatecall(calls[i]); // @> msg.value retained
    require(success);
}

Root cause#

The batch abstraction does not constrain or account for value across delegated subcalls; each sees the same transaction value.

Preconditions#

  • A payable function is reachable through batch.
  • That function uses msg.value to update balances or permissions.

Attack walkthrough#

  1. Exploit sends one ether to batch with two credit() calls.
  2. Both delegated calls observe 1 ether and increment credited.
  3. The Proof event at output.txt:381 shows 2 ether credited.

Diagrams#

sequenceDiagram participant E as Exploit participant L as Ladle.batch E->>L: 1 ETH + [credit, credit] L->>L: delegatecall credit (msg.value = 1 ETH) L->>L: delegatecall credit (msg.value = 1 ETH) L-->>E: credited = 2 ETH

Remediation#

Make batch non-payable unless value semantics are explicit, pass a per-call value budget, or enforce that at most one delegated call consumes msg.value.

How to reproduce#

BASH
cd evm-hack-registry/16976-use-of-delegatecall-in-a-payable-function-inside-a-loop-trai_exp
forge test -vvvvv

Sources#

Reference: https://github.com/trailofbits/publications/blob/master/reviews/YieldV2.pdf


Sources & further analysis#

Reproductions & code

Alerts & third-party analyses

  • Web3Sec X hacked database: search.
  • Rekt leaderboard: search.
  • Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.