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.
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
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.
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-registrymirror.
Vulnerability classes: vuln/dependency/unsafe-external-call · vuln/logic/state-update
Reproduction: self-contained synthetic Foundry reduction; see output.txt.
Key info#
| Field | Value |
|---|---|
| Loss | Future value-sensitive logic can count one payment multiple times |
| Vulnerable contract | Ladle.batch |
| Attacker EOA | 0x1111111111111111111111111111111111111111 |
| Attack contract | Ladle via Exploit |
| Attack tx | Exploit.run{value: 1 ether}() |
| Chain / block / date | Ethereum model · block 0 · 2021-06 |
| Compiler | solc 0.8.24 (synthetic) |
| Bug class | Payable 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#
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.valueto update balances or permissions.
Attack walkthrough#
Exploitsends one ether tobatchwith twocredit()calls.- Both delegated calls observe
1 etherand incrementcredited. - The
Proofevent at output.txt:381 shows 2 ether credited.
Diagrams#
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#
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
- Standalone PoC + full trace: 16976-use-of-delegatecall-in-a-payable-function-inside-a-loop-trai_exp (evm-hack-registry mirror).
- AuditVault finding: 16976-use-of-delegatecall-in-a-payable-function-inside-a-loop-trai.
Alerts & third-party analyses
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.