Reproduced Exploit

Burve — Incorrect handling of ERC4626 vaults with fees

1. Pool deposits user tokens into an ERC4626 that takes a 1% deposit fee. 2. Protocol still credits full value despite fewer shares minted. 3. User withdraws full credited value; 1% hole is socialized onto residual LPs. 4. HARM: residual insolvency (seed short 1e18 after Alice's round-trip).

Apr 2025Otheruntagged2 min read

Chain

Other

Category

untagged

Date

Apr 2025

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: 56950-h-1-incorrect-handling-of-erc4626-vaults-with-fees-sherlock. Standalone Foundry PoC and full write-up: 56950-h-1-incorrect-handling-of-erc4626-vaults-with-fees-sherlock_exp in the evm-hack-registry mirror.


Vulnerability classes: fee-accounting · direct-drain

Reproduction: self-contained Foundry PoC, offline, forge-std only. Full trace: output.txt.


Key info#

ImpactHIGH — depositors extract full value while fee hole hits residual LPs
ProtocolBurve multi-token pool (ValueFacet → ERC4626 vertex)
Vulnerable codeValueFacet.addValue deposits exact realNeeded into fee-taking ERC4626
Bug classFee-on-deposit not covered / not accounted
FindingSherlock 2025-04-burve · #56950 · H-1 · newspacexyz et al.
Reportsherlock-audit/2025-04-burve-judging
Fixitos-finance/Burve#71
Compiler^0.8.24 (PoC)

TL;DR#

  1. Pool deposits user tokens into an ERC4626 that takes a 1% deposit fee.
  2. Protocol still credits full value despite fewer shares minted.
  3. User withdraws full credited value; 1% hole is socialized onto residual LPs.
  4. HARM: residual insolvency (seed short 1e18 after Alice's round-trip).

The vulnerable code#

SOLIDITY
function addValue(address recipient, uint256 value) external {
    token.transferFrom(msg.sender, address(this), realNeeded);
    vault.deposit(realNeeded, address(this)); // @> VULN: no fee coverage; full value credited
    valueOf[recipient] += value;
    totalValue += value;
}

Fix: transfer extra tokens to cover fees, or credit only net shares.


Root cause#

Nominal value is booked 1:1 with pre-fee assets; vault fee is ignored.

Attack walkthrough#

  1. Seed pool: 1000 assets = 1000 value.
  2. Alice deposits 100; vault mints 99 shares; Alice credited 100 value.
  3. Alice withdraws 100 → redeems 100 shares from residual.
  4. HARM: seed left with 999 assets against 1000 credited value.

Diagrams#

flowchart TD A["Alice deposits 100 assets"] --> B["Fee vault takes 1%"] B --> C["99 shares minted"] C --> D["Protocol credits 100 value"] D --> E["Alice withdraws 100"] E --> F["Residual LP short 1 asset"]

Impact#

Users avoid underlying vault fees; last withdrawers eat the shortfall.

Sources#


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.