BurgerSwap (Demax) Exploit — Re-entrant Multi-Hop Swap Drains the WBNB Side of the Pool Twice

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

Vulnerability classes: vuln/reentrancy/cross-function · vuln/governance/flash-loan-attack

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. Verified vulnerable source: DemaxPlatform.sol.

Key info#

TL;DR#

BurgerSwap's DemaxPlatform router executes a multi-hop swap in two distinct phases:

1. It pre-computes all output amounts up-front from the current reserves (_getAmountsOut, DemaxPlatform.sol:692-706, called at :811).
2. It then walks the path hop-by-hop in _swap (:744-768), pulling the input token from the user with _innerTransferFrom (:825-833), which fires a transferNotify callback to a configurable transfer listener.

There is no re-entrancy guard anywhere on the swap path. The attacker deploys a fake ERC20 (FAKE) whose transferFrom re-enters the router mid-swap. By routing a FAKE -> BURGER -> WBNB swap, the attacker makes the router:

• pull FAKE from itself, which re-enters and performs a real BURGER -> WBNB swap against the live BURGER/WBNB pool — draining 4,478 WBNB, and then
• return to the original (now stale) loop and execute the cached BURGER -> WBNB hop, draining another 4,478 WBNB at the pre-re-entrancy price even though the pool's WBNB reserve had already collapsed.

The same liquidity is therefore sold for WBNB twice. The pool's WBNB reserve falls from ~9,067 to 128, and the attacker repays the flash loan and walks off with the pool's WBNB plus tens of thousands of BURGER. The PoC reproduces BURGER exploited: 110564 / WBNB exploited: 2398.

Background — what DemaxPlatform does#

DemaxPlatform (source) is BurgerSwap's Uniswap-V2-style router ("Demax"). It is the only contract that is allowed to drive the Demax pairs (each DemaxPair checks msg.sender == platform() before swapping). It differs from a vanilla V2 router in two security-relevant ways:

• It charges a DGAS fee and "notifies" a transfer listener on every token movement. Both _innerTransferFrom (:825) and _swap (:763-765) call _transferNotify (:967-974), which calls an external IDemaxTransferListener(TRANSFER_LISTENER).transferNotify(...). More importantly, the input token's own transferFrom is called via TransferHelper.safeTransferFrom (:831), and that token can be anything the attacker registers (BurgerSwap permissionlessly creates pairs / adds tokens on first addLiquidity, as seen at output.txt:265-472).
• It caches amounts across hops. swapExactTokensForTokens (:802-823) computes the entire amounts[] array once at :811, before any token moves, then passes that frozen array into _swap (:820) where each hop blindly uses amounts[i+1] (:756) as the exact output to request from the pair.

On-chain state of the victim BURGER/WBNB pair at fork block 7,781,159 (decoded from getReserves() at output.txt:41):

Note: by the time the attacker reaches the double-spend, the pool already holds far more WBNB than 3,038 — the attacker first pumps WBNB into the pool by buying BURGER, so the WBNB reserve at the moment of the double-drain is 9,067 WBNB (see the walkthrough).

The vulnerable code#

1. Amounts are frozen before any token moves#

function swapExactTokensForTokens(
    uint256 amountIn,
    uint256 amountOutMin,
    address[] calldata path,
    address to,
    uint256 deadline
) external ensure(deadline) returns (uint256[] memory amounts) {
    uint256 percent = _getSwapFeePercent();
    amounts = _getAmountsOut(amountIn, path, percent);   // ← (A) quote uses CURRENT reserves
    require(amounts[amounts.length - 1] >= amountOutMin, '...INSUFFICIENT_OUTPUT_AMOUNT');
    address pair = DemaxSwapLibrary.pairFor(FACTORY, path[0], path[1]);
    _innerTransferFrom(                                   // ← (B) pulls path[0]; for FAKE this RE-ENTERS
        path[0], msg.sender, pair,
        SafeMath.mul(amountIn, SafeMath.sub(PERCENT_DENOMINATOR, percent)) / PERCENT_DENOMINATOR
    );
    _swap(amounts, path, to);                             // ← (C) executes hops with the STALE quote from (A)
    _innerTransferFrom(path[0], msg.sender, pair, SafeMath.mul(amounts[0], percent) / PERCENT_DENOMINATOR);
    _swapFee(amounts, path, percent);
}

DemaxPlatform.sol:802-823

2. The hop loop blindly requests the cached output from each pair#

function _swap(uint256[] memory amounts, address[] memory path, address _to) internal {
    require(!isPause, "DEMAX PAUSED");
    require(swapPrecondition(path[path.length - 1]), '...');
    for (uint256 i; i < path.length - 1; i++) {
        (address input, address output) = (path[i], path[i + 1]);
        ...
        uint256 amountOut = amounts[i + 1];              // ← uses the frozen quote, not live reserves
        (uint256 amount0Out, uint256 amount1Out) = input == token0
            ? (uint256(0), amountOut) : (amountOut, uint256(0));
        address to = i < path.length - 2 ? DemaxSwapLibrary.pairFor(FACTORY, output, path[i + 2]) : _to;
        IDemaxPair(DemaxSwapLibrary.pairFor(FACTORY, input, output)).swap(amount0Out, amount1Out, to, new bytes(0));
        ...
    }
}

DemaxPlatform.sol:744-768

3. The re-entrancy door: input token's own transferFrom#

function _innerTransferFrom(address token, address from, address to, uint256 amount) internal {
    TransferHelper.safeTransferFrom(token, from, to, amount);  // ← token.transferFrom() — attacker-controlled for FAKE
    _transferNotify(from, to, token, amount);
}

DemaxPlatform.sol:825-833

Note the complete absence of a nonReentrant modifier: there is no lock guarding swapExactTokensForTokens / _swap, and the individual DemaxPair.swap calls happen one at a time across the loop, so a nested router call can freely operate on the same pair in between the cached hops.

Root cause — why it was possible#

A correct V2 router is safe even though it pre-computes amounts, because each pair's swap() enforces the constant-product invariant x·y ≥ k against its own current balances at call time: if the reserves moved between quote and execution, the pair's swap would revert (K check). BurgerSwap breaks this safety in two compounding ways:

1. Cached quote + no re-entrancy guard. The router freezes the multi-hop output amounts (:811) and then re-enters itself through the attacker's FAKE.transferFrom before the cached hops run. The pair's per-call K check does not save the protocol here, because the two BURGER→WBNB sales happen in two separate top-level swap() calls — the inner (nested) one and the outer (cached) one — and each one is internally consistent. There is no global invariant that says "the BURGER reserve I quoted against is the BURGER reserve I'm selling into." The router trusts its own stale amounts[].

2. The input token is attacker code. Because BurgerSwap lets anyone register a token and create a pair, the attacker controls the very function (FAKE.transferFrom) the router calls first inside the swap. The exact same finding shape appears in the Impossible Finance and several other 2021 router exploits.

Concretely, the path FAKE -> BURGER -> WBNB weaponizes this:

Hop 0 of the cached loop pulls FAKE from the attacker (_innerTransferFrom, :814). That call lands in FAKE.transferFrom, which re-enters the router with a fresh, correctly-priced BURGER -> WBNB swap that drains the live WBNB reserve. When the original loop resumes, hop 1 (BURGER -> WBNB) requests the cached WBNB output computed before the re-entrancy — selling the same liquidity into the already-drained pool at the old price, pulling a second, equal chunk of WBNB.

The pool's WBNB reserve is sold twice for the price of once.

Preconditions#

• The attacker can register an arbitrary token and create a Demax pair for it (permissionless addLiquidity path — output.txt:265-472 shows FAKE/BURGER being created on the fly).
• The router has no re-entrancy guard on swapExactTokensForTokens / _swap.
• Working capital in WBNB to (a) pump BURGER price up first and (b) seed the FAKE/BURGER pool. This is fully recovered intra-transaction, so the whole attack is flash-loanable — the PoC borrows 6,047 WBNB from the PancakeSwap USDT/WBNB pair via swap(...) + pancakeCall (BurgerSwap_exp.sol:33).

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

All figures below are decoded directly from the Sync / Swap events in output.txt. For the BURGER/WBNB pair, reserve0 = BURGER, reserve1 = WBNB.

The double-spend, side by side — both sells output the identical 4478568384980737... WBNB:

The second sale receives essentially the same WBNB as the first despite the pool already being half-empty — proof the router used the pre-re-entrancy quote.

Profit / loss accounting#

The PoC's closing logs confirm the spoils:

BURGER exploited: 110564
WBNB exploited: 2398

At late-May-2021 prices (WBNB ≈ $370, BURGER ≈ $9-10), the combined haul of ~2,398 WBNB plus 110,564 BURGER is in line with the **$3.2M** loss attributed to this incident.

Diagrams#

Sequence of the attack#

Pool state evolution (BURGER/WBNB victim pair)#

The flaw inside swapExactTokensForTokens / _swap#

Why it is theft: one liquidity slice, sold twice#

Remediation#

1. Add a global re-entrancy guard to the router. A single nonReentrant modifier on swapExactTokensForTokens / swapTokensForExactTokens / _swap would make the nested enter() swap revert, eliminating the double-spend entirely. This is the root fix.
2. Do not cache quotes across hops in the presence of external calls. Re-read each pair's reserves immediately before requesting its output, or push input tokens to the pair and let the pair compute the output (the modern V2 pattern), so a hop can never settle against a reserve state that differs from the one it was quoted against.
3. Treat the input token's transfer as untrusted. Because BurgerSwap permits arbitrary token registration, every token.transferFrom inside a swap is an external call to attacker code. Pull all required input before doing any pricing-sensitive work, follow strict checks-effects-interactions, and never re-enter the swap engine from a transfer callback.
4. Remove / harden the transferNotify listener hook. The _transferNotify external call on every transfer is an additional re-entrancy surface; if it must stay, it should be a trusted, immutable contract and must run after all state-affecting work, behind the guard.
5. Validate output against live reserves. After each hop, assert the WBNB actually received equals the amount the pair's current reserves can justify (i.e. re-run getAmountOut against post-call reserves), reverting on mismatch.

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 test build):

_shared/run_poc.sh 2021-05-BurgerSwap_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required (fork block 7,781,159 is from May 2021). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most pruned public BSC RPCs fail here with header not found / missing trie node.
• Result: [PASS] testExploit() with BURGER exploited: 110564 and WBNB exploited: 2398.

Expected tail:

Ran 1 test for test/BurgerSwap_exp.sol:Exploit
[PASS] testExploit() (gas: 7277280)
Logs:
  BURGER exploited: 110564
  WBNB exploited: 2398

References:

• Lunaray — BurgerSwap attack analysis: https://lunaray.medium.com/burgerswap-attack-analysis-c0345541d69
• QuillAudits — BurgerSwap flash-loan attack analysis: https://quillhashteam.medium.com/burgerswap-flash-loan-attack-analysis-888b1911daef
• SlowMist Hacked — https://hacked.slowmist.io/ (BurgerSwap, BSC, ~$3.2M).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2021-05-BurgerSwap_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: BurgerSwap_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "BurgerSwap (Demax) 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.