BH Exploit — Spot-Reserve-Priced Liquidity Manager Drained via Flash-Loan Price Manipulation

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

Vulnerability classes: vuln/oracle/price-manipulation · vuln/oracle/spot-price · vuln/governance/flash-loan-attack

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. The umbrella DeFiHackLabs repo does not whole-compile under forge test, so this PoC was extracted into a standalone project. Full verbose trace: output.txt. PoC source: test/BH_exp.sol. Verified BH token source: sources/BH_CC61CC/BH.sol (the actual vulnerable logic lives in the unverified liquidity-manager 0x8cA7835aa30b025b38A59309DD1479d2F452623a, whose behavior is reconstructed from the trace).

Key info#

TL;DR#

The "Recovery" liquidity manager lets a user deposit BUSDT (selector 0x33688938) and later withdraw (selector 0x4e290832). On deposit it adds BUSDT+BH to the BUSDT/BH PancakeSwap pair and records the user's principal at the pool's current ratio. On withdraw it computes how much LP to redeem — and therefore how much BUSDT to hand back — from the pool's instantaneous spot reserves at withdraw time rather than from the recorded principal or a manipulation-resistant oracle.

The attacker, funded entirely by flash loans, did the following inside one transaction:

1. Bootstrapped a position in the manager: 12× Upgrade(lpToken) (a small escalating-fee accrual/registration routine) plus a large deposit 0x33688938(3,000,000 BUSDT).
2. Crashed the BH price in the pair by dumping 22,000,000 BUSDT → 209,261,023 BH and sending that BH to a throwaway sink (0x5b9dd1De...). This collapses the pair from 1.40M BUSDT / 251.27M BH to 26.41M BUSDT / 42.01M BH — BH's spot price (BUSDT per BH) jumps roughly 40×.
3. Withdrew 10× via 0x4e290832. Because the withdrawal math reads the now-distorted spot reserves, each redemption returns far more BUSDT than the position is actually worth, repeatedly redeeming BH.balanceOf(pair) * 55% worth of LP and skimming BUSDT back to the attacker.
4. Repaid all flash loans and kept the surplus: 1,277,481 BUSDT (~$1.27M) of net profit.

The BH token contract itself (verified) is a trivial whitelist-gated ERC20 — it is not where the bug lives; it is merely the asset paired against BUSDT in the manipulated pool. The exploit is a classic spot-reserve-priced liquidity/redemption routine that trusts a flash-loan-manipulable AMM price.

Background — the actors#

The PoC (test/BH_exp.sol) wires together a deep flash-loan stack purely to raise working capital cheaply (DODO pools charge 0 fee), then routes everything through the manager:

• DODO pools (DPPOracle1/2/3, DPP, DPPAdvanced) — five nested 0-fee BUSDT flash loans totalling 1,521,678 BUSDT.
• PancakeV3 BUSDT_USDC — a 15,000,000 BUSDT flash() (paid back with a 0.05% fee = 7,500 BUSDT).
• WBNB/BUSDT v2 pair — a swap() that pulls 10,000,000 BUSDT out (paid for in BUSDT inside the v2 callback).
• Router — PancakeRouter v2 (0x10ED4...), used by the manager for addLiquidity / removeLiquidity / swaps.
• UnverifiedContract1 = the manager (0x8cA7835..., labelled Recovery for its factory role) — the vulnerable contract. Key entry points observed in the trace:
  • Upgrade(address lpToken) — pulls an escalating BUSDT fee from the caller (10, 20, … BUSDT), adds a tiny amount of liquidity, swaps, and distributes BH to a set of reward addresses; it effectively registers / accrues the caller as a participant.
  • 0x33688938(uint256 amount) — deposit: pulls amount BUSDT, adds BUSDT+BH liquidity to the pair, records the caller's principal, and refunds leftover BH.
  • 0x4e290832(uint256 amount) — withdraw: redeems LP from the pair and returns BUSDT to the caller, sized from the pool's current spot reserves.

The BUSDT/BH pair starts the transaction (block 32,512,073) at roughly:

The vulnerable code#

What is verified: the BH token (not the bug)#

The on-chain-verified BH token (sources/BH_CC61CC/BH.sol) is a plain whitelist-gated ERC20 with no fee-on-transfer and no AMM hooks:

function _transfer(address sender, address to, uint amount) internal {
    require(isWhite[sender] || isWhite[to], "ERC20: not white");
    require(sender != address(0), "ERC20: transfer from the zero address");
    require(amount > 0, "Transfer amount must be greater than zero");
    require(_balances[sender] >= amount,"exceed balance!");

    _balances[sender] = _balances[sender].sub(amount);
    _balances[to] = _balances[to].add(amount);
    emit Transfer(sender, to, amount);
}

There is nothing exploitable here beyond the whitelist gate — and that gate is satisfied because the pair and the manager are whitelisted. The vulnerability is in the manager's redemption accounting, not in the token.

What is unverified but reconstructable from the trace: the manager's withdraw#

The manager's withdraw 0x4e290832 is not source-verified, but the trace makes its logic unmistakable. The PoC drives it with a withdrawal sizing keyed to the live pool BH balance:

// test/BH_exp.sol:117-125  — attacker's withdrawal loop
i = 0;
while (i < 10) {
    uint256 lpAmount = (BH.balanceOf(busdt_bh_lp) * 55) / 100;   // <-- spot-reserve-derived size
    (success,) = address(UnverifiedContract1).call(
        abi.encodeWithSelector(bytes4(0x4e290832), lpAmount));
    require(success, "Call to function with selector 0x4e290832 fail");
    ++i;
}

Inside each 0x4e290832 call the trace shows the manager:

1. read BH.balanceOf(pair) and BUSDT.balanceOf(pair) (output.txt:2116-2119);
2. derive an LP amount, approve the router, and call Router.removeLiquidity(BUSDT, BH, lpAmount, 0, 0, manager, …) (output.txt:2127);
3. the pair burn() returns BUSDT+BH at the current (manipulated) ratio — Burn(amount0: 14,564,485 BUSDT, amount1: 23,172,077 BH) (output.txt:2161);
4. re-add a slice of liquidity, then transfer the BUSDT surplus to the caller — BUSDT::transfer(ContractTest, 12,379,812 BUSDT) (output.txt:2172-2173).

The single load-bearing flaw: the amount of value returned to the user is a function of the pool's instantaneous reserves, with no check that the spot price is consistent with the price at deposit time and no manipulation-resistant oracle. Because reserves are flash-loan-manipulable, the attacker controls the exchange rate at which they redeem.

Root cause#

A constant-product AMM's spot price (reserveQuote / reserveBase) is trivially movable: a single large swap shifts it arbitrarily for the rest of the transaction. Any protocol that prices deposits/withdrawals/collateral off the pair's live reserves — instead of a TWAP, an external oracle, or the user's recorded principal — can be drained by:

deposit at the honest price → move the price with a flash-funded swap → withdraw at the manipulated price → repay the flash loan → keep the difference.

The BH manager does exactly this. Concretely:

1. Withdrawal value derived from live reserves. 0x4e290832 sizes the LP redemption (and thus the BUSDT paid out) from BH.balanceOf(pair) / pool reserves at call time, not from the principal recorded at deposit time.
2. No oracle / no TWAP. There is no manipulation-resistant price source; getReserves() is the price source.
3. Deposit and withdraw are independently callable in the same transaction, so the attacker can straddle a self-induced price move between them.
4. The price move is free. The 22M-BUSDT manipulation swap is fully recovered: the BUSDT goes into the pair and comes back out (and then some) through the over-credited withdrawals.

The verified BH token's whitelist (isWhite) is not a meaningful defense here — the pair and manager are whitelisted so all transfers in the attack path succeed.

Preconditions#

• A liquidity manager that prices redemptions off the pair's spot reserves (satisfied by 0x8cA7835...).
• The attacker can deposit then withdraw within one transaction, straddling a price move (satisfied: 0x33688938 and 0x4e290832 are separate public selectors).
• Enough working capital to (a) seed a deposit and (b) move the pool's BH price hard. All of it is flash-loaned (1.52M BUSDT from DODO + 15M from PancakeV3 + 10M from the WBNB/BUSDT pair), so the attacker needs ~0 of its own capital — the PoC starts the attacker at 0 BUSDT (test/BH_exp.sol:59).
• BH whitelist permits the pair/manager/router transfers (true at the fork block).

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

All reserve figures are taken from Sync / getReserves events in output.txt. For the pair, reserve0 = BUSDT, reserve1 = BH.

Why the 55%-of-BH-balance sizing works: by keying the withdrawal amount to the pool's current BH balance, each iteration redeems a fixed fraction of whatever is left, and because redemptions are priced at the manipulated (BUSDT-rich) ratio, BUSDT flows out far faster than the position's honest value. Ten iterations walk the pool down from 26.4M BUSDT to ~47k BUSDT, with the difference (minus flash-loan repayments) ending up with the attacker.

Profit / loss accounting (BUSDT)#

(Reported headline loss ~$1.27M, matching the final on-chain BUSDT balance read at output.txt tail: Attacker BUSDT balance after attack: 1277481.82….)

Diagrams#

Sequence of the attack#

Pool state evolution#

Why redemption is theft: deposit price vs. withdraw price#

The flaw inside the withdraw path#

Remediation#

1. Never price deposits/withdrawals off live AMM reserves. Redemption value must be derived from the user's recorded principal (and any genuinely earned yield), not from getReserves() at withdraw time. The manager already pulls the user's BUSDT on deposit — return value relative to that recorded basis, not the spot pool ratio.
2. Use a manipulation-resistant price source. If a pool price is unavoidable, use a TWAP (Uniswap/Pancake v2 cumulative-price oracle over a window) or an independent oracle (Chainlink/DODO oracle price), and reject quotes that deviate from it beyond a tight band.
3. Break the deposit/withdraw straddle. Enforce a time delay or a "no withdraw in the same block as a deposit/large reserve change" rule so a flash-loaned price move cannot sit between a deposit and a withdrawal.
4. Bound single-operation reserve impact / use slippage controls. Reject withdrawals when the pair's spot price has moved more than a small percentage versus a reference (oracle/TWAP) within the operation, and pass real amountMin values to removeLiquidity instead of 0.
5. Add reentrancy / per-tx accounting guards. Make the redemption accounting independent of any value the same transaction can transiently inflate.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo does not whole-compile under forge test).

_shared/run_poc.sh 2023-10-BH_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 32,512,073). Most pruned public RPCs will fail with header not found / missing trie node; use an archive node.
• Result: [PASS] testExploit() — attacker BUSDT goes from 0 to 1,277,481 BUSDT.

Expected tail:

Ran 1 test for test/BH_exp.sol:ContractTest
[PASS] testExploit() (gas: 6430822)
Logs:
  Attacker BUSDT balance before attack: 0.000000000000000000
  Attacker BH balance before attack: 0.000000000000000000
  Attacker BUSDT balance after attack: 1277481.822359750672220700
  Attacker BH balance after attack: 22080807.209252526442543347

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

References: Beosin — https://twitter.com/BeosinAlert/status/1712139760813375973 ; Decurity — https://twitter.com/DecurityHQ/status/1712118881425203350 ; SlowMist Hacked — https://hacked.slowmist.io/ (BH, BSC, ~$1.27M).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2023-10-BH_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: BH_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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