The DRLVaultV3 Exploit: A Slippage Design Failure

On Nov 10, 2025, DRLVaultV3, a USDC–WETH rebalance vault, was exploited due to a design flaw. Fortunately, the attacker is a whitehat-tagged address, and the protocol should recover the funds. In this blog, we analyze the root cause of the vulnerability and outline mitigation strategies.

Incident Overview

Date: Nov 10, 2025

Platform: Ethereum (ETH)

Attacker Address: 0xC0ffeEBABE5D496B2DDE509f9fa189C25cF29671 (white hat attacker)

Vulnerable Contract: 0x6A06707ab339BEE00C6663db17DdB422301ff5e8 (DRLVaultV3)

Attack Transaction: 0xe3eab35b288c086afa9b86a97ab93c7bb61d21b1951a156d2a8f6f5d5715c475

Exploit Flow

1. The attacker first borrowed approximately 14M USDC from the Morpho Blue vault.

2. They then heavily bought WETH using this USDC, causing the WETH price in the pool to spike sharply. As a result, the pool began reporting that WETH was extremely expensive, and USDC was worth very little WETH.

3. Next, the attacker triggered the vault’s swapToWETH function, prompting the vault to buy WETH using its USDC balance—at the now manipulated price.

4. Finally, the attacker sold the previously purchased WETH back into the pool, capturing a profit from the manipulated price difference.

Root Cause

The fundamental issue lies in how the vault computes amountOutMinimum for swaps. Instead of receiving this value from the user (off-chain) or deriving it from a trusted oracle, the contract calculates it on-chain using the current pool quote within the same transaction.

This design makes the vault’s slippage protection dependent on a manipulable reference price.

function swapToWETH(uint256 _amount) public returns (uint256 _amountOut) {
    // ... setup ...

    // FATAL FLAW: Asking the chain for the current price
    uint256 expectedAmountOut = getQuoteForUSDC(fee, _amount);

    // The contract accepts the Quoter’s price minus 0.5%
    uint256 _amountOutMinimum = (expectedAmountOut * (10000 - slippageBps)) / 10000;

    IV3SwapRouter.ExactInputSingleParams memory params = IV3SwapRouter.ExactInputSingleParams({
        tokenIn: tokenIn,
        tokenOut: WETH,
        fee: fee,
        recipient: address(this),
        amountIn: _amount,
        amountOutMinimum: _amountOutMinimum, // Uses the manipulated minimum
        sqrtPriceLimitX96: 0
    });

    _amountOut = swapRouter.exactInputSingle(params);
}

The problem is not the slippage tolerance (0.5% is normal), but that the slippage baseline is mutable. When the attacker shifts the pool price by 10%, the vault’s computed minimum also shifts by 10%, effectively nullifying all protection.

This flaw leaves both swapToUsdc and swapAllToWETH vulnerable to classic sandwich and price-manipulation attacks.

Mitigation

Effective slippage protection must rely on a price reference that is independent of any in-transaction price manipulation.

The recommended approach is to compute amountOutMinimum off-chain (on the client or backend) and pass it into the contract as a parameter. This ensures the minimum output is anchored to an external, trusted price source rather than the volatile on-chain state at execution time.

Alternatively, the contract can use a trusted oracle price (e.g., Chainlink or a time-weighted average price) to derive amountOutMinimum. By basing calculations on oracle data rather than instantaneous pool prices, the contract becomes resistant to sandwich and price manipulation attacks.