Reaper Farm Exploit — ERC-4626 `redeem()` / `withdraw()` Missing Allowance Check

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: 2022-08-ReaperFarm_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/ReaperFarm_exp.sol.

Vulnerability classes: vuln/logic/missing-allowance · vuln/access-control/missing-check

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains several unrelated PoCs that do not whole-compile, so this one was extracted). Full verbose trace: output.txt. PoC: test/ReaperFarm_exp.sol. Verified-source note (Fantom chainid 250 is no longer served by the Etherscan V2 API): sources/SOURCE_FETCH_STATUS.md.

Key info#

TL;DR#

ReaperVaultV2 is an ERC-4626-style yield vault. Its public redeem(uint256 shares, address receiver, address owner) and withdraw(uint256 assets, address receiver, address owner) functions let a caller specify an arbitrary owner whose shares get burned and an arbitrary receiver who gets the underlying. The standard ERC-4626 requires that when msg.sender != owner, the vault spend the caller's allowance over owner's shares (_spendAllowance / _decreaseAllowance). Reaper's implementation omitted that check entirely.

So anyone could call:

ReaperVault.redeem(victimShares, attacker, victim);

The vault burns the victim's shares, withdraws the corresponding underlying from its strategy, and sends every token to attacker. No approval from the victim is ever required or checked.

In this PoC the attacker redeems victim 0x59cb9F…022A's entire 12,461.358730 rfUSDC balance and walks away with 12,505.610392 USDC — the ~0.35% surplus over the share count is the yield the vault had accrued (price-per-share > 1.0). Repeated across every vault and every depositor, this totaled ~$1.7M.

Background — what ReaperVaultV2 does#

ReaperVaultV2 is a single-asset vault on Reaper Farm. Depositors send USDC and receive rfUSDC shares; the vault forwards the USDC to one or more strategies that farm yield (here, lending USDC into the Scream / Iron Bank money market via the intermediate vault 0x7A688CFc…CAEf2). The share price rises as the strategy accrues interest.

Withdrawal is the ERC-4626 burn-and-pay flow:

1. Burn shares from owner's balance.
2. If the vault doesn't hold enough idle underlying, instruct a strategy to withdraw() the shortfall back to the vault.
3. Transfer the resulting assets of underlying to receiver.

The ERC-4626 standard makes step 1 conditional on authorization: a caller who is not the owner must hold (and spend) an ERC-20-style allowance over the owner's shares. Reaper copied the rest of the 4626 flow but dropped the authorization gate.

The trace confirms the vault held 0 idle USDC (USDC.balanceOf(vault) == 0 at output.txt:38), so the entire payout had to be pulled out of the live strategy — which is exactly what the trace's deep withdraw → cToken redeem subtree does before the final transfer to the attacker.

The vulnerable code#

The verified Fantom source could not be re-fetched programmatically (Etherscan V2 dropped Fantom chainid 250; see sources/SOURCE_FETCH_STATUS.md). The browser source is at ftmscan.com/address/0xcdA5dea…#code (PoC header cites #code#F1#L324). The snippets below are the canonical Reaper ReaperVaultV2 withdrawal code as published in the post-mortems, and every line is corroborated against the executed trace in output.txt.

1. redeem — caller-controlled owner, no allowance gate#

function redeem(uint256 shares, address receiver, address owner)
    external
    override
    returns (uint256 assets)
{
    // ⚠️ NO check that msg.sender == owner
    // ⚠️ NO _spendAllowance(owner, msg.sender, shares)
    assets = (balance() * shares) / totalSupply();   // pro-rata assets for the shares
    _withdraw(assets, shares, receiver, owner);
}

function withdraw(uint256 assets, address receiver, address owner)
    external
    override
    returns (uint256 shares)
{
    // ⚠️ Same omission as redeem()
    shares = (assets * totalSupply()) / balance();
    _withdraw(assets, shares, receiver, owner);
}

2. _withdraw — burns owner's shares, pays receiver#

function _withdraw(uint256 assets, uint256 shares, address receiver, address owner)
    internal
    returns (uint256)
{
    _burn(owner, shares);                       // ← victim's shares destroyed

    if (token.balanceOf(address(this)) < assets) {
        // pull the shortfall out of the strategies
        uint256 remaining = assets - token.balanceOf(address(this));
        // ... loop over withdrawalQueue, call IStrategy(strat).withdraw(remaining) ...
    }

    token.safeTransfer(receiver, assets);       // ← underlying sent to attacker
    emit Withdraw(msg.sender, receiver, owner, assets, shares);
    return assets;
}

What is missing — the standard ERC-4626 guard (OpenZeppelin reference) that every compliant vault has at the top of redeem/withdraw:

if (msg.sender != owner) {
    _spendAllowance(owner, msg.sender, shares);   // <-- absent in ReaperVaultV2
}

Because that line was never there, owner is a purely caller-supplied parameter, and _burn(owner, shares) succeeds against anyone's balance.

Root cause — why it was possible#

ERC-4626's withdraw/redeem take an explicit owner argument precisely so a third party (a router, a zap contract, a keeper) can move assets on behalf of a depositor — but only with prior approval. The entire security of that three-argument form rests on a single conditional: if the caller is not the owner, consume the caller's allowance over the owner's shares.

Reaper's ReaperVaultV2 implemented the mechanics of the 4626 withdrawal (pro-rata math, share burn, strategy pull-back, transfer to receiver) but left out the authorization. The result is that the owner parameter degenerates into "whose funds would you like to steal?":

1. owner is attacker-controlled and unauthenticated. Nothing ties owner to msg.sender or to an allowance. _burn(owner, shares) only checks that owner has the shares, not that the caller may spend them.
2. receiver is also attacker-controlled. The underlying is paid to a caller-supplied address, so the value lands directly in the attacker's pocket — no second step needed.
3. The vault auto-liquidates the strategy to fund the theft. Even with zero idle balance in the vault, _withdraw pulls the assets out of the live Scream/Iron-Bank position to satisfy the (unauthorized) redemption.

This is a textbook "missing access control on a standard-interface function." The fix is one if statement.

Preconditions#

• The victim holds a non-zero rfUSDC share balance (here 12,461.358730 shares — output.txt:27).
• The vault can source the underlying — either idle or, as here, by pulling from its strategy. The PoC needs no capital: it is a pure third-party redemption.
• No approval, no flash loan, no price manipulation, no timing. The attacker simply names the victim as owner and itself as receiver.

The PoC reproduces the exact on-chain conditions by forking Fantom at block 44,045,899 (test/ReaperFarm_exp.sol:32) and calling redeem with the victim's full balance (test/ReaperFarm_exp.sol:43-44).

Step-by-step attack walkthrough (with on-chain numbers from the trace)#

All figures below are taken directly from output.txt. USDC and rfUSDC both use 6 decimals.

The only entry point invoked is redeem — there is no setup, no approval, no secondary call.

Why the attacker receives more than the share count#

redeem pays out assets = balance() * shares / totalSupply() — the pro-rata assets, not the share count. The vault's share price had drifted above 1.0 from accrued lending interest, so 12,461.358730 shares were worth 12,505.610392 USDC at the fork block — a +44.251662 USDC (~0.35%) premium. The trace's getPricePerFullShare() returns 1,014,201,552,892,377,654 (≈1.0142e18, i.e. ~1.0142 per share — output.txt:278), consistent with the surplus.

Profit / loss accounting (USDC, 6 decimals)#

Across all Reaper vaults and all depositors the same one-call drain summed to ~$1.7M. (Reaper later announced compensation funded from its own treasury.)

Diagrams#

Sequence of the attack#

The flaw inside redeem / _withdraw#

Correct vs. actual authorization path#

Remediation#

1. Add the ERC-4626 allowance gate (the actual fix Reaper shipped). At the top of both withdraw and redeem, before burning:

   SOLIDITYCopy

   if (msg.sender != owner) {
       _spendAllowance(owner, msg.sender, shares);
   }
   

   (or the explicit allowance/_approve decrement pattern). This single conditional makes the owner parameter meaningless to an unauthorized caller — _spendAllowance reverts on insufficient allowance.

2. Prefer a battle-tested base. Inherit from OpenZeppelin's ERC4626 (or Solmate's ERC4626) rather than hand-rolling the withdrawal flow. Both enforce the allowance check by construction; the bug class disappears.

3. Test the negative case. Add a unit test asserting that redeem(shares, attacker, victim) from a non-approved caller reverts. The absence of exactly this test is what let the omission ship.

4. Treat every standard-interface parameter as adversarial. Any function that accepts an owner/from/account it then debits must authenticate that debit against msg.sender (equality or allowance). Grep the codebase for _burn(owner / _burn(from and verify each is preceded by an auth check.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has several unrelated PoCs that fail to whole-compile under forge test):

_shared/run_poc.sh 2022-08-ReaperFarm_exp --mt testExploit -vvvvv

• RPC: a Fantom Opera archive endpoint is required to serve historical state at block 44,045,899. foundry.toml points fantom at https://rpcapi.fantom.network.
• Result: [PASS] testExploit(). The attacker, starting from 0 USDC, ends with 12,505.610392 USDC drained from victim 0x59cb9F…022A, whose rfUSDC balance goes to 0.

Expected tail:

Ran 1 test for test/ReaperFarm_exp.sol:Attacker
[PASS] testExploit() (gas: 1307399)
Logs:
  This is a simple PoC that shows how attacker abuse the ReaperVaultV2 contract
  Victim ReaperUSDCVault balance: 12461.358730
  Attacker USDC balance: 0.000000
  Exploit...
  Victim ReaperUSDCVault balance: 0.000000
  Attacker USDC balance: 12505.610392

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

References:

• Reaper Farm official post-mortem — https://twitter.com/Reaper_Farm/status/1554500909740302337
• Beosin alert — https://twitter.com/BeosinAlert/status/1554476940593340421
• Verified contract — https://ftmscan.com/address/0xcdA5deA176F2dF95082f4daDb96255Bdb2bc7C7D#code

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-08-ReaperFarm_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: ReaperFarm_exp.sol.

Alerts & third-party analyses

• Original alert / thread: post on X.
• DeFiHackLabs incident explorer: search "Reaper Farm Exploit".
• 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.