Annex Finance `Liquidator` Exploit — Unauthenticated Flash-Swap Callback Drains the Contract

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

Vulnerability classes: vuln/access-control/missing-auth · vuln/reentrancy/cross-contract

One-line summary: Annex's Liquidator PancakeSwap flash-swap callback (pancakeCall) never verifies that it initiated the swap, so anyone can drive the callback from a fake attacker-owned pair, make the contract approve + transfer its own WBNB balance as a bogus "flash-loan repayment", and walk off with every token the contract held.

Reproduction: the PoC compiles & runs in this isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source: Liquidator.sol.

Key info#

TL;DR#

Liquidator is a flash-loan liquidation helper for the Annex Finance lending market (a Compound/Venus fork on BSC). To liquidate underwater borrowers it borrows the repay asset from a PancakeSwap pair via a flash swap, performs the liquidation in the pancakeCall callback, and pays the pair back.

The callback (Liquidator.sol:985-1096) makes exactly one security check:

require(msg.sender == IPancakeFactory(FACTORY).getPair(token0, token1));

This only proves the caller is some canonical PancakeSwap pair. It does not prove that the Liquidator itself started the swap. Worse, every parameter that decides what the callback does (borrower, repayAToken, seizeAToken) is decoded straight from attacker-supplied data, and the untrusted sender argument is ignored entirely.

So an attacker:

1. Deploys a worthless token ("Shit Coin") and creates a brand-new, attacker-owned PancakeSwap pair ShitCoin/WBNB.
2. Calls pair.swap(0, X, Liquidator, data) where X = WBNB.balanceOf(Liquidator) and data = abi.encode(attacker, attacker, attacker). PancakeSwap dutifully sends X WBNB to the Liquidator and invokes Liquidator.pancakeCall(attacker, 0, X, data).
3. Inside the callback, because repayAToken == seizeAToken == attacker, the Liquidator (a) safeApproves the attacker contract to spend its WBNB, (b) calls the attacker's no-op liquidateBorrow/redeem stubs, and (c) transfers (X*1000/997)+1 of its own WBNB to the attacker's pair as the "flash-loan repayment".
4. The attacker then removeLiquidity from its own pair (recovering the WBNB it just received) and transferFroms the Liquidator's remaining WBNB using the allowance the callback granted in step (a).

Net result: the contract's entire WBNB balance (≈7.2258 WBNB) ends up in the attacker's hands; final profit 7.2224 WBNB. The DODO flash loan is just free working capital and is repaid in full.

Background — what Liquidator does#

Annex Finance is a Compound-style money market on BSC (aBEP20/aBNB cToken-equivalents, a Comptroller, and a PriceOracle). Liquidator (source) is an off-chain-operated bot contract that liquidates underwater positions without holding inventory, by borrowing the repay asset from a PancakeSwap pair via a flash swap:

• liquidate(...) / liquidateS(...) pick a pair, compute the repay amount, and call IPancakePair(pair).swap(amount0, amount1, address(this), data) (:949-975). The pair then "lends" the asset to the Liquidator and re-enters it through pancakeCall.
• pancakeCall(...) (:985-1096) is where the real work happens: approve the repay aToken, call liquidateBorrow, redeem the seized collateral, optionally swap it, and finally transfer the debt back to the pair so the flash swap settles.

The design intent is: only Liquidator.liquidate() ever starts these swaps, so when pancakeCall runs, the WBNB it is about to spend was just flash-borrowed and must be repaid. The bug is that nothing enforces "only Liquidator started the swap."

On-chain facts at the fork block (read from the trace):

That ~7.2258 WBNB sitting idle in the contract is the entire prize.

The vulnerable code#

1. The callback authenticates the pair but not the initiator#

function pancakeCall(address sender, uint amount0, uint amount1, bytes calldata data) override external {
    // Unpack parameters sent from the `liquidate` function
    // NOTE: these are being passed in from some other contract, and cannot necessarily be trusted
    (address borrower, address repayAToken, address seizeAToken) = abi.decode(data, (address, address, address));

    address token0 = IPancakePair(msg.sender).token0();
    address token1 = IPancakePair(msg.sender).token1();
    require(msg.sender == IPancakeFactory(FACTORY).getPair(token0, token1));   // ⚠️ ONLY check
    ...

Liquidator.sol:985-992.

The lone require confirms msg.sender is a genuine factory-deployed pair. But any factory pair qualifies — including one the attacker just created for a token they minted. Two checks that should exist are missing:

• require(sender == address(this), ...) — proves the Liquidator itself initiated the swap. The sender argument is literally the comment's "cannot necessarily be trusted" value, yet it is never used for authorization.
• A whitelist / allowlist of pairs the Liquidator is actually liquidating against.

2. The repayAToken == seizeAToken branch hands the attacker an approval and a transfer#

if (repayAToken == seizeAToken) {
    uint amount = amount0 != 0 ? amount0 : amount1;
    address estuary = amount0 != 0 ? token0 : token1;          // == WBNB in the attack

    // Perform the liquidation
    IERC20(estuary).safeApprove(repayAToken, amount);          // ⚠️ approves attacker to spend WBNB
    ABep20(repayAToken).liquidateBorrow(borrower, amount, seizeAToken);  // ⚠️ attacker stub, returns 0

    // Redeem aTokens for underlying ERC20
    ABep20(seizeAToken).redeem(IERC20(seizeAToken).balanceOf(address(this)));  // ⚠️ attacker stub

    // Compute debt and pay back pair
    IERC20(estuary).transfer(msg.sender, (amount * 1000 / 997) + 1);   // ⚠️ pays its OWN WBNB
    return;
}

Liquidator.sol:994-1008.

When the attacker sets repayAToken == seizeAToken == attackerContract:

• estuary is the asset being borrowed in the flash swap (WBNB), and safeApprove(repayAToken, amount) makes the Liquidator approve the attacker to spend amount of its WBNB.
• liquidateBorrow and redeem are calls into the attacker contract, which returns harmless stubs (no real liquidation occurs).
• The final transfer(msg.sender, (amount*1000/997)+1) pays the pair back — but the WBNB used is the Liquidator's own balance plus the just-borrowed amount, so the contract is spending its own funds to settle a flash swap it never wanted.

The attacker chose the easiest of the four branches (repayAToken == seizeAToken), but the root flaw is generic to the whole function: the callback trusts that it was entered as part of its own liquidation.

Root cause — why it was possible#

A PancakeSwap/Uniswap-V2 flash swap re-enters the recipient via IPancakeCallee.pancakeCall(sender, amount0, amount1, data). The msg.sender is the pair; the sender argument is whoever called pair.swap(). Secure flash-swap consumers MUST verify both:

1. msg.sender is a pair they trust (the Liquidator does this), and
2. sender == address(this) — i.e. this contract initiated the swap (the Liquidator does not do this).

Without check (2), the callback is a public function that anyone can drive with arbitrary arguments, simply by deploying their own pair and calling swap with the victim as the to recipient. The four design decisions that compose into the loss:

1. sender ignored. The one value that distinguishes "I started this" from "a stranger started this" is decoded-around and discarded, despite an in-code comment flagging it as untrusted.
2. data is fully attacker-controlled. borrower, repayAToken, seizeAToken come straight from the swap's data payload, so the attacker picks which branch runs and which contracts get called.
3. The aToken addresses are arbitrary contracts. Because they are not validated against the Comptroller's market list, the attacker passes its own contract, whose liquidateBorrow/redeem/balanceOf/redeem are no-op stubs that let the callback "succeed".
4. The callback spends the contract's own balance. In the safe path the WBNB transferred out was flash-borrowed; in the attack the contract also holds idle WBNB, so safeApprove + transfer leak real funds, not just the borrowed amount.

Preconditions#

• The Liquidator holds a non-zero balance of the asset the attacker chooses as the flash-swap token (here WBNB ≈7.2258). Accumulated liquidation revenue made this true.
• A working PancakeSwap factory (0xcA143Ce3...) on which the attacker can create a fresh pair for a token they control — always available.
• A small amount of WBNB to seed the fake pair's liquidity (8 WBNB here, borrowed for free from DODO and fully repaid). The exploit is effectively zero-capital / flash-loanable; the loan is convenience, not necessity.

No timing, no governance, no admin role — the callback is permissionlessly reachable.

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

All figures are taken directly from output.txt. WBNB = 0xbb4C…095c, Liquidator = 0xe65E…63E3, attacker pair = 0xd060…65a3, DODO DVM = 0xFeAFe…d681.

Why the contract's funds move at all#

In a legitimate liquidation, the WBNB that the callback transfers back in step 7 is exactly the WBNB the pair just lent in step 4 — net zero for the Liquidator. Here the attacker's pair lent the Liquidator's own WBNB back to it (step 4 sends to the Liquidator), and the Liquidator repaid with that same balance plus the 0.3% fee (step 7). The pair therefore ends up with more WBNB than it started with, and the attacker harvests that surplus via removeLiquidity (step 8). Separately, the safeApprove in step 5 lets the attacker transferFrom whatever WBNB the contract still has after step 7 (step 9). Between the two, the contract's full balance leaves.

Profit / loss accounting (WBNB)#

The attacker started with 0 WBNB of its own capital (the 8 WBNB came from a free DODO flash loan that was repaid), and ended holding 7.2224 WBNB, which is essentially the entire 7.2258 WBNB the Liquidator had accumulated (the ~0.0034 WBNB difference is PancakeSwap's 0.25%/0.3% fees and the minimum-liquidity / dust left in the throwaway pair).

Diagrams#

Sequence of the attack#

Pool / balance state evolution#

The flaw inside pancakeCall#

Remediation#

1. Authenticate the swap initiator. Add require(sender == address(this), "untrusted initiator"); at the top of pancakeCall. This is the single fix that closes the hole — only swaps the Liquidator itself started can re-enter the callback. (This is the canonical Uniswap-V2 flash-swap pattern, and the in-code comment already warns that sender "cannot necessarily be trusted.")
2. Pin the expected pair per call. Have liquidate() record the exact pair address it is about to swap against (e.g. a transient storage slot or a hashed-commitment of the call), and assert in pancakeCall that msg.sender equals that pinned value — so an arbitrary factory pair cannot be substituted.
3. Validate the aToken arguments. Reject repayAToken/seizeAToken that are not registered Annex markets (require(comptroller.markets(repayAToken)) / seizeAToken), so attacker-controlled stub contracts cannot stand in for real cTokens.
4. Never leave idle inventory in the bot. Sweep accumulated revenue to the recipient after each liquidation (or on a schedule). A callback bug is far less damaging if the contract holds ~0 spendable balance between operations.
5. Tighten approvals. Approve the exact aToken for the exact amount and reset to zero immediately after use; do not approve attacker-supplied addresses at all (a consequence of fix #3).

Any one of fixes #1–#3 individually prevents this exploit; #1 is the minimal, correct change.

How to reproduce#

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

_shared/run_poc.sh 2022-11-Annex_exp -vvvvv

• RPC: a BSC archive endpoint is required (the fork pins block 23,165,446). Most public BSC RPCs prune historical state at that block and fail with header not found / missing trie node; use an archive provider.
• Result: [PASS] testExploit() with the attacker WBNB balance ≈ 7.2224.

Expected tail (output.txt):

Ran 1 test for test/Annex_exp.sol:ContractTest
[PASS] testExploit() (gas: 4589764)
Logs:
  [End] Attacker WBNB balance after exploit: 7.222370557374026863

Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 6.58s

References: AnciliaInc — https://twitter.com/AnciliaInc/status/1593690338526273536 ; attack tx 0x3757d177482171dcfad7066c5e88d6f0f0fe74b28f32e41dd77137cad859c777 (BSC).

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2022-11-Annex_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: Annex_exp.sol.
• Attack transaction: view on explorer.

Alerts & third-party analyses

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