BOSS Exploit — Helper Mint/Burn Drains the Pair's BOSS Reserve, then a Degenerate-Reserve Swap Loop Empties the USDT Side

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

Vulnerability classes: vuln/access-control/missing-auth · vuln/oracle/price-manipulation

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source (the AMM contract whose invariant is broken): PancakePair.sol.

Key info#

TL;DR#

1. The attacker borrows 1,250,000 USDT from a Moolah flash loan (output.txt:67) and enters its own onMoolahFlashLoan callback.
2. It calls the privileged BOSS helper's userMint(100,000 USDT) (output.txt:77). The helper mints fresh BOSS, adds BOSS+USDT liquidity to the pair (pushing its reserves to ~110,215 USDT / ~6,623,926 BOSS, output.txt:129), and — critically — its accounting _burns a chunk of BOSS straight out of the pair and sync()s the smaller balance (output.txt:152-159).
3. It then swaps the remaining ~1,150,000 flash-USDT into BOSS with the helper as recipient (output.txt:173).
4. It calls BOSS helper's userBurn(...) (output.txt:213). The helper swaps the attacker's BOSS back out for USDT, then _burns the pair's BOSS down to a literal 10 wei and sync()s — leaving the pair holding ~700,898 USDT against 10 wei of BOSS (output.txt:278). The constant product k has collapsed; BOSS is now priced near-infinitely.
5. It then runs a 155-iteration loop (test/BOSS_exp.sol:129-139): each pass transfers bossReserve / 10 BOSS into the pair and calls the pair's low-level swap() directly, pulling out getAmountOut(netBossIn, bossReserve, usdtReserve) USDT. Because bossReserve is tiny (10, 11, 12, … wei) relative to the USDT reserve, each swap legitimately satisfies the pair's k check yet siphons a large slice of USDT (output.txt:305-319).
6. After 155 passes the pair's USDT side is drained to ~4.83 USDT (output.txt:6130). The attacker repays the 1,250,000-USDT flash (output.txt:6136) and forwards the residue — 10,210.15 USDT — to its EOA (output.txt:6148, output.txt:6165).

The bug is not in the vanilla PancakePair: it is that BOSS's privileged helper can _burn the pair's own BOSS balance and sync(), manufacturing a pool whose BOSS reserve is 10 wei while its USDT reserve is ~700K. From that degenerate state the constant-product formula prices a single wei of BOSS at a huge USDT amount, and the attacker mines that mispricing 155 times.

Background — what BOSS does#

BOSS is a BSC ERC20 paired against USDT on PancakeSwap V2. It ships with a privileged BOSS helper contract (0x9781…DDc1) that exposes userMint(uint256) and userBurn(uint256). From the trace, the helper's behaviour is:

• userMint(usdtAmount) — pulls usdtAmount USDT from the caller (output.txt:78), reads the on-chain price via BOSS.getPrice() (which itself reads the pair's getReserves, output.txt:86-93), mints BOSS, addLiquidity to the BOSS/USDT pair (output.txt:100), mints additional BOSS to the caller and to itself (output.txt:140-151), and then _burns a slice of the pair's BOSS balance followed by pair.sync() (output.txt:152-159).
• userBurn(amount) — used in reverse: it swaps the caller's BOSS into USDT through the pair (output.txt:252-264), then _burns the pair's residual BOSS down to dust and sync()s (output.txt:271-278).

Both helper paths share the same fatal primitive: they delete BOSS from the live AMM pair's token balance and force the pair to adopt the reduced balance as its reserve. The pair contract itself is a stock PancakeV2 pair — its swap() only enforces the constant-product k check on the balances it currently sees (PancakePair.sol:472-476); it has no way to know its BOSS reserve was annihilated out from under it.

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

The whole game is the relation between the two reserves after step 4: ~700,898 USDT sitting against 10 wei of BOSS (output.txt:278). USDT is decimal-18 on BSC, so 10 wei of BOSS is ~1e-17 BOSS — effectively zero — yet the AMM still treats it as a real reserve to price against.

The vulnerable code#

The verified source we can cite verbatim is the PancakeV2 pair (token1 = BOSS). The pair is correct for a well-behaved token — the exploit weaponises it via BOSS's helper. The two subsections below pin (1) the AMM invariant the attack abuses and (2) the sync() primitive the helper uses to corrupt the reserve. The BOSS-token/helper source is not verified in this project folder; its userMint/userBurn behaviour is taken from the execution trace and cited to output.txt.

1. The pair's swap() enforces k only on the balances it currently holds#

function swap(uint amount0Out, uint amount1Out, address to, bytes calldata data) external lock {
    require(amount0Out > 0 || amount1Out > 0, 'Pancake: INSUFFICIENT_OUTPUT_AMOUNT');
    (uint112 _reserve0, uint112 _reserve1,) = getReserves(); // gas savings
    require(amount0Out < _reserve0 && amount1Out < _reserve1, 'Pancake: INSUFFICIENT_LIQUIDITY');
    ...
    uint amount0In = balance0 > _reserve0 - amount0Out ? balance0 - (_reserve0 - amount0Out) : 0;
    uint amount1In = balance1 > _reserve1 - amount1Out ? balance1 - (_reserve1 - amount1Out) : 0;
    require(amount0In > 0 || amount1In > 0, 'Pancake: INSUFFICIENT_INPUT_AMOUNT');
    { // scope for reserve{0,1}Adjusted, avoids stack too deep errors
    uint balance0Adjusted = (balance0.mul(10000).sub(amount0In.mul(25)));
    uint balance1Adjusted = (balance1.mul(10000).sub(amount1In.mul(25)));
    require(balance0Adjusted.mul(balance1Adjusted) >= uint(_reserve0).mul(_reserve1).mul(10000**2), 'Pancake: K');
    }
    _update(balance0, balance1, _reserve0, _reserve1);
    emit Swap(msg.sender, amount0In, amount1In, amount0Out, amount1Out, to);
}

(PancakePair.sol:452-480)

The k check balance0Adjusted · balance1Adjusted ≥ reserve0 · reserve1 · 10000² is the only protection. When reserve1 (BOSS) is 10 wei, reserve0 · reserve1 is minuscule, so the inequality is satisfied by an absurdly small BOSS input against a huge USDT output. The pair behaves exactly as designed — the design simply does not survive a reserve that was secretly burned to dust.

2. sync() blindly adopts the contract's current token balance as the new reserve#

// force reserves to match balances
function sync() external lock {
    _update(IERC20(token0).balanceOf(address(this)), IERC20(token1).balanceOf(address(this)), reserve0, reserve1);
}

(PancakePair.sol:491-493)

function _update(uint balance0, uint balance1, uint112 _reserve0, uint112 _reserve1) private {
    require(balance0 <= uint112(-1) && balance1 <= uint112(-1), 'Pancake: OVERFLOW');
    ...
    reserve0 = uint112(balance0);
    reserve1 = uint112(balance1);
    blockTimestampLast = blockTimestamp;
    emit Sync(reserve0, reserve1);
}

(PancakePair.sol:366-379)

sync() trusts that token balances only move through mint/burn/swap/transfers the pair can reason about. BOSS's helper violates that trust: it calls BOSS.burn(pair, …) (an ERC20 burn that decrements the pair's BOSS balance) and then pair.sync(). The pair dutifully records the smaller balance as its new reserve. In the trace this is the Sync(reserve0: 700898…, reserve1: 10) event (output.txt:278) — BOSS deleted from the pool with zero USDT removed.

3. The helper's burn-from-pool primitive (observed in the trace)#

Inside userBurn, after swapping the attacker's BOSS to USDT, the helper burns the pair's remaining BOSS and re-syncs:

BOSS token::burn(BOSS/USDT Pancake pair, 855488023369279514116608)   // output.txt:271
  emit Transfer(pair -> 0x0, 855488023369279514116608)               // output.txt:272
  BOSS/USDT Pancake pair::sync()                                      // output.txt:273
    emit Sync(reserve0: 700898212858770136364236, reserve1: 10)      // output.txt:278

(output.txt:271-278)

This is the classic "burn from the pool" anti-pattern: one reserve side is destroyed in-place, the AMM re-syncs the smaller balance, and k collapses in favour of whoever can next push that side back up cheaply.

Root cause — why it was possible#

Three design facts compose into the loss:

1. A privileged helper can burn the pair's reserve and sync(). userMint and userBurn both call BOSS.burn(pair, …) + pair.sync() (output.txt:152-159, output.txt:271-278). This is an un-compensated one-sided reserve removal: BOSS leaves the pool, no USDT does. The stock pair has no defence — sync() exists precisely to accept whatever balance the token currently reports (PancakePair.sol:491-493).

2. The attacker controls how far down the BOSS reserve is burned. userBurn is driven to leave exactly 10 wei of BOSS in the pair (output.txt:278); the PoC chooses the burn amount as pairBossBalance - 10 (test/BOSS_exp.sol:124-126). With the BOSS reserve at 10 wei and the USDT reserve at ~700,898, the constant product is degenerate: BOSS is priced near-infinitely, so tiny BOSS inputs buy huge USDT outputs.

3. The pair's k check is satisfiable from the degenerate state. Because the pair genuinely receives the net BOSS the attacker transfers in (BOSS is fee-on-transfer, so the pair keeps the post-tax amount), amount1In > 0 and the balanceAdjusted product still clears reserve0 · reserve1 · 10000² (PancakePair.sol:472-475). The attacker calls swap() directly (not through the router), pre-computing the USDT it is allowed to take with getAmountOut(netBossIn, bossReserve, usdtReserve) against the current tiny reserves (test/BOSS_exp.sol:131-138). Each pass legally extracts roughly usdtReserve · netBossIn / (bossReserve + netBossIn) — and with bossReserve ≈ netBossIn that is ~half the USDT side per early pass.

The flash loan and userMint are stage-setting: they inflate the pool with USDT (~700,898 by step 4) so there is a large prize, and they supply the BOSS the attacker feeds back in. The actual theft is the 155-pass swap() loop mining the burned-to-dust reserve.

Preconditions#

• Access to the BOSS helper's userMint/userBurn. Both are callable by the attacker in the trace with no privileged-role revert (output.txt:77, output.txt:213); the helper itself holds the BOSS mint right and performs the burn(pair) + sync().
• The BOSS/USDT pair is a live PancakeV2 pair whose reserve the helper burns directly (token0 = USDT, token1 = BOSS, output.txt:90).
• Working capital in USDT to inflate the pool's USDT side and to round-trip. Peak outlay is the 1,250,000-USDT Moolah flash (output.txt:67); it is repaid in-transaction (output.txt:6136), so the attack is fully flash-loanable — the attacker started with 0 USDT (output.txt:37-38).
• BOSS being fee-on-transfer is incidental: the pair keeps the net BOSS received, which is what lets the k check pass; the attacker simply re-derives netBossIn from the pair's balance delta (test/BOSS_exp.sol:135-137).

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

The pair's token0 = USDT, token1 = BOSS, so reserve0 = USDT and reserve1 = BOSS. All figures are taken directly from the Sync / Swap / getReserves / getAmountOut lines in output.txt. Amounts are raw (18-decimal) wei; human approximations in parentheses.

Why "1 wei of BOSS drains ~9% on pass 1, then ever less": PancakeSwap's getAmountOut is out = (in·9975·reserveOut) / (reserveIn·10000 + in·9975). On pass 1 reserveIn = 10 (BOSS) and in = 1, so out ≈ (9975·700,898e18) / (10·10000 + 9975) ≈ 0.0907 · 700,898e18 ≈ 63,573e18. As the loop proceeds the BOSS reserve climbs (10 → 11 → … → 1,492,372) and the USDT reserve falls, so each pass extracts a smaller absolute amount — which is why 155 passes are needed to wring the side down to ~4.83 USDT rather than a single swap.

Profit / loss accounting (USDT, raw wei)#

The pair's USDT reserve fell from ~700,898 (the inflated post-userMint level) to ~4.83 (output.txt:6130). The attacker pre-pocketed ~559,317 USDT inside userBurn (output.txt:253-254) and ~63,573 + 52,989 + 44,845 + … across the 155-pass loop; after repaying the 1,250,000-USDT flash and accounting for the 100,000 USDT spent on userMint, the net residue forwarded to the EOA is 10,210.15 USDT (output.txt:6165) — comfortably above the PoC's 10,000-USDT assertion (test/BOSS_exp.sol:71).

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside the helper's burn-and-sync#

Why the burn is theft: constant-product before vs. after#

Why each magic number#

• flashAmount = 1,250,000 ether (test/BOSS_exp.sol:95) — the Moolah USDT flash. 100,000 is consumed by userMint; the remaining ~1,150,000 is swapped into BOSS to load the pool with USDT (peaking the USDT reserve so the eventual drain has a large prize). The full 1,250,000 is repaid at the end (output.txt:6136).
• helperMintUsdt = 100,000 ether (test/BOSS_exp.sol:112) — seeds the helper's mint+addLiquidity so the helper mints enough BOSS to itself and the attacker, and so the pool reserves are pushed into a regime the later burn can exploit (output.txt:77).
• pairBossDust = 10 (test/BOSS_exp.sol:125) — the target BOSS reserve left in the pair after userBurn's burn. Burning the pair down to exactly 10 wei (output.txt:278) makes reserveIn in getAmountOut tiny, so a single wei of BOSS prices against the full ~700,898-USDT reserve.
• grossBossIn = bossReserve / 10 (test/BOSS_exp.sol:133) — each pass feeds in one-tenth of the current BOSS reserve. With BOSS being fee-on-transfer, the PoC recomputes the net received (netBossIn, test/BOSS_exp.sol:136) and prices the swap on it so the pair's k check always clears.
• drainLoopCount = 155 (test/BOSS_exp.sol:129) — the number of passes needed to grind the USDT reserve from ~700,898 down to ~4.83 (output.txt:6130). Each pass takes a shrinking slice (the BOSS reserve grows by the net input each time), so a constant fraction-per-pass converges geometrically.
• assertGt(profit, 10_000 ether) (test/BOSS_exp.sol:71) — the PoC's success threshold; the realised profit is 10,210.15 USDT (output.txt:6165).

Remediation#

1. Never burn from a live AMM pair's balance. The helper's BOSS.burn(pair, …) + pair.sync() is an un-compensated one-sided reserve removal. A burn must only ever destroy tokens the protocol owns (its own balance / treasury). Removing the burn-from-pool path eliminates the bug entirely.
2. Gate the privileged helper. userMint/userBurn perform mint and burn-from-pool with no effective access control in the trace. Restrict any function that can move pool reserves to a trusted keeper/role, and forbid the pool-burn branch from any externally callable entry point.
3. Forbid lpPair / pool addresses as burn targets. Validate that the burn target is not a Uniswap/Pancake pair (a real pair exposes token0()/token1()/getReserves()); reject burning from any address that is an AMM pool.
4. Don't let a token's transfer/burn hooks desynchronise pool reserves. If deflation must reach LPs, route it through the pair's own burn() (LP redemption) so both reserves move together and k is preserved — never via _burn(pool) + sync().
5. Cap single-operation reserve impact. Any operation that can move a pool reserve by more than a small percentage should revert. Burning a reserve from ~855K down to 10 wei in one call is the red flag that enabled the entire drain.

How to reproduce#

The PoC runs offline against a local anvil fork served from this folder's anvil_state.json (the setUp does vm.createSelectFork("http://127.0.0.1:8546", 102671877), test/BOSS_exp.sol:46-47). The shared harness boots anvil from the saved state and runs the test:

_shared/run_poc.sh 2026-06-BOSS_exp --mt testExploit -vvvvv

• Chain: BSC (chainId 56), fork block 102,671,877. State is pre-baked in anvil_state.json, so no public archive RPC is needed.
• EVM: foundry.toml sets evm_version = 'cancun'.
• Result: [PASS] testExploit() logging Attacker Final USDT Balance: 10210.153605566961015705.

Expected tail (from output.txt:3-6 and output.txt:6165-6170):

Ran 1 test for test/BOSS_exp.sol:ContractTest
[PASS] testExploit() (gas: 8151823)
Logs:
  Attacker Final USDT Balance: 10210.153605566961015705
...
  emit log_named_decimal_uint(key: "Attacker Final USDT Balance", val: 10210153605566961015705 [1.021e22], decimals: 18)
  VM::assertGt(10210153605566961015705 [1.021e22], 10000000000000000000000 [1e22], "USDT profit")
Suite result: ok. 1 passed; 0 failed; 0 skipped; finished in 18.21s (17.08s CPU time)

Reference: audit_911 — https://x.com/audit_911/status/2063819348305985748 (BOSS, BSC, ~$10.2K).

Sources & further analysis#

Reproductions & code

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

Alerts & third-party analyses

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