Crypto exploits

RouterDrain exploit analysis

On 2026-09-07, an attacker on BNB Chain used a DEX router with an unset factory address to drain ~62.28 WBNB across 29 victims through fake Uniswap V3-style pool callbacks.

Reported loss
~62.28 WBNB across 29 victims (3 reconstructed here: OCEAN, Kandura, SATURN), per DeFiHackLabs
Occurred
Logged

Logged as “2026-09-07: Permissionless Swap Entry Lets A Fake V3 Pool Abuse Router Allowances on RouterDrain”.

Analysis1 min read

A DEX-router (swap-aggregator) contract on BNB Chain accepted arbitrary caller-supplied addresses as Uniswap V3-style pools. The router's permissionless swap entry (selector 0x33411b5e) took a route list with an attacker-chosen pool and called pool.swap() on it without verifying that the address belonged to a factory-derived V3 pool. The router's factoryV3() getter returned the zero address, so there was no canonical pool address it could even compute to check against. A contract that merely implemented pool.swap() could therefore re-enter the router's own uniswapV3SwapCallback and pull any token from any address that had standing approval to the router.

The attacker (EOA 0xB929C7215c0ec8EbAD5fBf73b1Da63bccfFf1896) ran the exploit in a single transaction on block 120524634. The router sat at 0xa331fde028e6F17425AB9333c39ae43722340d24 (proxy -> unverified implementation 0x241f743e...). The attacker's FakePool implemented only pool.swap(); when the router called it, the fake pool re-entered the router's uniswapV3SwapCallback with data that named a victim address as the payer. The router decoded that field and ran transferFrom(victim, msg.sender, amount) under the victim's standing token approval. In the real transaction the attacker substituted a different victim address than the one the router had originally passed, demonstrating that nothing in the callback bound payer to the actual swap initiator.

The README totals ~62.28 WBNB across 29 victims. The PoC reconstructs three representative victims, which is enough to demonstrate the bug. The on-chain exploit bootstrapped gas with a 1 WBNB PancakeV2 flash-swap and later sold the looted tokens back to WBNB; those are downstream monetisation rather than the vulnerability itself.

The underlying issue is that the router's factoryV3() is unset. With no factory there is no way to derive a real pool address and no list of legitimate pools against which to validate the route. Even if a factory were set, the callback would still need to verify that msg.sender is one of the factory's pools and that the payer field in data corresponds to the original initiator, neither of which was enforced.

Sources read (3)

Other exploits

Query every incident yourself — free, no signup

Updated 14 Oct 2026. Figures are as reported by the sources listed above and are not independently verified.