Reproduced Exploit

Non-existent module delegatecall appears successful — unchecked target

delegatecall to an EOA or destroyed contract returns true. Ladle's module registry can therefore mark a no-code address as valid and report a successful module execution that did nothing.

Jun 2021Ethereumdependency2 min read

Loss

Batches silently skip a module call and continue with stale state

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: 16975-lack-of-contract-existence-check-on-delegatecall-may-lead-to. Standalone Foundry PoC and full write-up: 16975-lack-of-contract-existence-check-on-delegatecall-may-lead-to_exp in the evm-hack-registry mirror.


Vulnerability classes: vuln/dependency/unsafe-external-call · vuln/input-validation/missing

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

Key info#

FieldValue
LossBatches silently skip a module call and continue with stale state
Vulnerable contractLadle.moduleCall
Attacker EOA0x1111111111111111111111111111111111111111
Attack contractLadle via Exploit
Attack txExploit.run()
Chain / block / dateEthereum model · block 0 · 2021-06
Compilersolc 0.8.24 (synthetic)
Bug classDelegatecall lacks code-existence validation

TL;DR#

delegatecall to an EOA or destroyed contract returns true. Ladle's module registry can therefore mark a no-code address as valid and report a successful module execution that did nothing.

Background#

Yield V2's Ladle exposes both batched self-calls and registered module calls. The audit warns that neither path checks extcodesize before delegating.

The vulnerable code#

SOLIDITY
(bool success, bytes memory ret) = module.delegatecall(data); // @> no code check
require(success, "module failed");

Root cause#

The registry's boolean membership check is treated as proof of executable code; the EVM's empty-account delegatecall behavior is ignored.

Preconditions#

  • An administrator registers an incorrect or later-destroyed module address.
  • A user invokes moduleCall or a batch containing it.

Attack walkthrough#

  1. Exploit registers 0xBEEF as a module.
  2. moduleCall delegates to the no-code account and gets (true, "").
  3. The Proof event at output.txt:375 records the false success.

Diagrams#

flowchart TD A[Bad module address] --> B[Ladle.delegatecall] B --> C[true + empty returndata] C --> D[Batch continues without module effects]

Remediation#

Require module.code.length > 0 before every delegatecall and document that selfdestruct/non-deployed modules cannot be treated as successful targets.

How to reproduce#

BASH
cd evm-hack-registry/16975-lack-of-contract-existence-check-on-delegatecall-may-lead-to_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.