Biswap V3Migrator Exploit — Arbitrary `recipient` LP Theft via Unauthorized `migrate()`

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

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

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 whole-compile, so this one was extracted). Full verbose trace: output.txt. PoC: test/Biswap_exp.sol. Verified vulnerable source: contracts_periphery_V3Migrator.sol.

Key info#

TL;DR#

Biswap's V3Migrator is a periphery helper meant to let a user move their own Uniswap-V2-style LP into a Biswap V3 concentrated-liquidity position. Its migrate() function takes a fully caller-supplied MigrateParams struct and, on its very first line, does:

IBiswapPair(params.pair).transferFrom(params.recipient, params.pair, params.liquidityToMigrate);

(contracts_periphery_V3Migrator.sol:51).

It pulls LP tokens out of params.recipient — an arbitrary address chosen by the caller — and never checks that msg.sender is that recipient, or that the caller is authorized to spend recipient's LP. The function's own interface comment even states liquidityToMigrate is "expected to be balanceOf(msg.sender)" (IV3Migrator.sol:11), but nothing in the code enforces that expectation.

Because the victim had previously approved the migrator to spend their LP token (a normal prerequisite for using the migrate flow), any attacker could call migrate() with recipient = victim and drain the victim's LP. The attacker abuses the freedom further: the migrator burns the victim's LP, keeps the underlying BTCB + USDT in the migrator contract, and then the attacker performs a second migrate() against a self-deployed fake pair that reports those same balances, redirecting the migrator's safeTransfer refund of the real tokens to the attacker (:85-104).

Net result in the PoC: the attacker ends up holding the victim's 28.149 BTCB (plus a V3 position funded with the victim's 53,553 BSC-USD). Profit = the victim's entire LP position.

Background — what V3Migrator does#

V3Migrator (source) is a standard "V2 → V3" liquidity migration helper, structurally a fork of Uniswap's V3Migrator. Its single relevant entry point, migrate(MigrateParams):

1. Burns V2 liquidity — transfers liquidityToMigrate LP from params.recipient into the pair, then calls pair.burn(address(this)) so the underlying token0/token1 land in the migrator.
2. Mints a V3 position — approves the LiquidityManager and calls mint(...) to deposit the burned tokens into a Biswap V3 pool, with the NFT going to params.recipient.
3. Refunds dust — whatever the V3 mint didn't consume is safeTransfer'd back to params.recipient.

The intended user flow is: a user approves the migrator for their own LP, then calls migrate() with recipient = themselves. The fatal assumption is that recipient is the caller.

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

The vulnerable code#

1. migrate() pulls LP from an arbitrary recipient with no authorization#

function migrate(MigrateParams calldata params) external override returns(uint refund0, uint refund1){

    // burn v2 liquidity to this address
    IBiswapPair(params.pair).transferFrom(params.recipient, params.pair, params.liquidityToMigrate); // ⚠️ no auth on recipient
    (uint256 amount0V2, uint256 amount1V2) = IBiswapPair(params.pair).burn(address(this));            //    underlying lands in migrator
    ...

(contracts_periphery_V3Migrator.sol:48-52)

There is no require(msg.sender == params.recipient), no signature check, no permit, no pull from msg.sender. Every field of params — pair, recipient, token0, token1, fee, liquidityToMigrate — is attacker-controlled. The only implicit requirement is that params.recipient has approved the migrator for at least liquidityToMigrate LP, which the victim had done.

2. The dust refund is steered by the caller's token0/token1/recipient#

    if (amount0V3 < amount0V2) {
        ...
        refund0 = amount0V2 - amount0V3;
        ...
        safeTransfer(params.token0, params.recipient, refund0);   // ⚠️ token & recipient both caller-chosen
    }
    if (amount1V3 < amount1V2) {
        ...
        refund1 = amount1V2 - amount1V3;
        ...
        safeTransfer(params.token1, params.recipient, refund1);
    }

(contracts_periphery_V3Migrator.sol:80-105)

The amounts amount0V2/amount1V2 are taken from the burn result, and safeTransfer moves any "unused" balance to params.recipient using params.token0/params.token1. The attacker can therefore engineer a migrate() call where amount0V2/amount1V2 describe a real token balance the migrator is currently holding, while the V3 mint consumes ~none of it, so the entire balance is refunded to an attacker-chosen address.

Root cause — why it was possible#

Two independent flaws compound:

1. Authorization confusion between msg.sender and recipient. migrate() spends recipient's LP via transferFrom, but treats recipient purely as a destination field. The correct invariant — "only the owner of the LP (or someone they authorized) may migrate it" — is never expressed. Any pre-existing approval to the migrator becomes a free spend for anyone. This is the same "arbitrary from" / "approval-as-a-weapon" class that has drained countless periphery routers and migrators.

2. The migrator burns to itself and refunds based on caller-controlled token addresses. Because burn(address(this)) deposits the underlying into the migrator and the refund path trusts params.token0/token1 and params.recipient, the attacker can run a second migrate() against a self-deployed fake pair whose burn() returns the same numbers the migrator just acquired — tricking the migrator into safeTransfer-ing the real BTCB/USDT it is holding to the attacker as "dust refund."

The interface even documents the broken assumption:

uint256 liquidityToMigrate; // expected to be balanceOf(msg.sender) (IV3Migrator.sol:11)

"Expected" was never enforced. The comment is the spec; the code violates it.

Preconditions#

• The victim has an outstanding LP approval to the migrator (pair.allowance(victim, migrator) ≥ liquidityToMigrate). This is the normal precondition for ever using the migrate feature, so any user who had prepared to migrate (or who used it once with a non-zero leftover allowance) was exposed.
• The victim holds the LP at attack time (the migrator pulls balanceOf(victim)-worth in the PoC).
• No capital, flash loan, or special role is required from the attacker — only gas. The attacker deploys a few helper contracts (a fake ERC20 pair) to capture the refund.

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

For the victim pair, token0 = BTCB (0x2170…F8), token1 = BSC-USD (0x55d3…55). All figures below are taken directly from the Transfer / Burn / Migrate events in output.txt.

PoC final balances (test address stands in for the attacker contract):

this token0 before: 0.000000000000000000   (BTCB)
this token1 before: 0.010000000000000000   (seed USDT)
this token0 after : 28.149267765302306856  (BTCB stolen)
this token1 after : 0.010000000000008780   (USDT dust)

(output.txt:5-10)

Profit / loss accounting#

The attacker walks off with the victim's full LP value: the BTCB side as raw tokens and the USDT side as a freshly minted V3 NFT position they own. DeFiHackLabs reports the headline loss as ~$72K.

Diagrams#

Sequence of the attack#

Authorization flaw inside migrate()#

Where the value goes — two-migrate redirection#

Remediation#

1. Spend only the caller's LP. Pull liquidity from msg.sender, not from a caller-supplied recipient:
   SOLIDITYCopy

   IBiswapPair(params.pair).transferFrom(msg.sender, params.pair, params.liquidityToMigrate);
   

   If migrating on behalf of someone is a genuine feature, require an explicit, scoped authorization (EIP-2612 permit, an on-chain allowlist, or a signed migration intent) — never a bare standing ERC20 approval.
2. Never treat recipient as both the LP source and the refund destination. Separate "who pays" (msg.sender) from "who receives" so a stolen approval can't be redirected.
3. Validate the pair against the factory. Reject any params.pair / params.token0 / params.token1 that is not a canonical Biswap pair, so a self-deployed FakePair can never be passed in. The fake-pair leg of the exploit dies if pair must be factory-derived from (token0, token1).
4. Tighten the refund path. Compute refunds from the migrator's actual measured token balance delta, derive token addresses from the validated pair (not from caller input), and send dust back to msg.sender, not an arbitrary address.
5. Honor the documented spec. The interface says liquidityToMigrate is "balanceOf(msg.sender)" — assert it. Specs that live only in comments are not enforced.

How to reproduce#

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

_shared/run_poc.sh 2023-06-Biswap_exp --mt testExploit -vvvvv

• RPC: a BSC archive endpoint is required — the test forks at block 29,554,461 (vm.createFork("bsc", 29554461)); most public BSC RPCs prune that far back and fail with header not found / missing trie node.
• Result: [PASS] testExploit(), with the attacker's BTCB balance going from 0 to 28.149267765302306856 BTCB.

Expected tail:

Ran 1 test for test/Biswap_exp.sol:ContractTest
[PASS] testExploit() (gas: 8408183)
Logs:
  liquidity to migrate: 1094357092264218434277
  this token0 before: 0.000000000000000000
  this token1 before: 0.010000000000000000
  this token0 after: 28.149267765302306856
  this token1 after: 0.010000000000008780

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

Reference: MetaTrust alert — https://twitter.com/MetaTrustAlert/status/1674814217122349056 (Biswap V3Migrator, BSC, ~$72K).

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

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