Skip to main content
• 6 min read

OLPC/LABUBU PancakeSwap V2 Pool
Exploit: $1.1M Drained via Burn-Reserve Mismatch

$1.1M was drained from the OLPC/LABUBU pool on PancakeSwap V2 after an OLPC burn bug desynced reserves and let the attacker exit through USDT.

AUTOSEC.DEVAUTOSEC.DEV
OLPC/LABUBU PancakeSwap V2 Pool Exploit: $1.1M Drained via Burn-Reserve Mismatch
  • Incident Date: June 20, 2026
  • Target: OLPC/LABUBU PancakeSwap V2 pool on BNB Chain
  • Target Overview: PancakeSwap is a multichain decentralized exchange. The affected component was a third-party OLPC/LABUBU PancakeSwap V2 liquidity pool on BNB Chain, and PancakeSwap later said its own smart contracts had no identified issue in the initial investigation.
  • Total Loss: Approximately $1.1 million; ExVul reported a 1,115,903 USDT exit and an attacker net of roughly $960,000.
  • Reported Attacker Address: 0x18d6c39ae9e537f948aa2212d44d8c23944fc188
  • Reported Drained Pool: 0xedb7dcb4cdfec957f8df5cbf5e94229a6cc9f365
  • Attack Vector: Smart-contract logic flaw / token-burn reserve desynchronization

Incident Review & Technical Details​

1. Attack Path​

  1. A small OLPC input reached the vulnerable path: ExVul reported that the attacker routed approximately 10 OLPC through an attacker contract and into the OLPC/LABUBU PancakeSwap V2 pair on BNB Chain. That interaction triggered abnormal token burning from the pool.
  2. OLPC and LABUBU balances were burned out of the pair: According to ExVul, the transaction burned approximately 51.9 million OLPC and 124,000 LABUBU to 0x...dead from the pair address 0xedb7...f365. The key failure was that the pool's real token balances changed sharply while its cached reserves were not resynchronized in time.
  3. Cached reserves diverged from balanceOf(pair): Once the actual balances and cached reserves no longer matched, the constant-product assumptions behind the pool no longer reflected the real asset state. ExVul described the pattern as consistent with a deflationary or burn-on-transfer token desynchronizing a constant-product pair's reserves.
  4. The attacker swept LABUBU and routed into USDT: The attacker drained the LABUBU side, routed value through the LABUBU/WBNB pool and then the WBNB/USDT pool, and exited with 1,115,903 USDT.
  5. Funds moved cross-chain and into Tornado Cash: PeckShield reported that the attacker bridged the stolen funds to Ethereum, deposited 633.4 ETH into Tornado Cash, and sent 0.0221 BNB plus 0.0411 ETH to a dead address.

2. Impact Scope​

  • Protocol-Level Loss: Public reporting converged on approximately $1.1 million drained from the OLPC/LABUBU pool, with ExVul reporting a 1,115,903 USDT exit and approximately $960,000 attacker net.
  • Affected Component: The affected component was the OLPC/LABUBU PancakeSwap V2 pair on BNB Chain, not a confirmed compromise of PancakeSwap's core platform contracts.
  • Affected Tokens and Contracts: ExVul identified OLPC at 0x58815cdf9955121a6274680ab396a36fc9e00000, LABUBU at 0x3494dfe19b721dac6c5c8d7470c8f89548177777, and the drained pair at 0xedb7dcb4cdfec957f8df5cbf5e94229a6cc9f365.
  • Routing Pools: The reported exit path moved through LABUBU/WBNB 0xdfacdc33e913710ead31ee40f9c5363ea673c421 and WBNB/USDT 0x16b9a82891338f9ba80e2d6970fdda79d1eb0dae.
  • Fund-Flow Risk: The bridge to Ethereum and 633.4 ETH Tornado Cash deposit reduce near-term recovery visibility and make exchange or bridge coordination time-sensitive.
  • Attribution Gap: Some analysts described the token-side setup as suspicious, but the reviewed sources did not include an official final attribution or a confirmed rug-pull determination.

3. Official Statements​

  • PancakeSwap: PancakeSwap said it was aware of reports concerning the OLPC/LABUBU pool on BNB Chain and that its initial investigation found no issue with PancakeSwap's smart contracts. The team said it would continue investigating and asked users to verify information through official channels.
  • PeckShieldAlert: PeckShieldAlert reported the approximately $1.1 million loss and the post-exploit fund flow to Ethereum, Tornado Cash, and dead addresses.
  • ExVul: ExVul published the attacker address, token contracts, drained pair, routing pools, attack transaction, USDT exit amount, and the reserve-desynchronization hypothesis.
  • Yu Xian / SlowMist: Yu Xian, founder of SlowMist, said the incident appeared to stem from severe imbalance in the OLPC/LABUBU pair. He also reported that the OLPC _update logic could burn value * decimalsValue OLPC when conditions were met, and that decimalsValue had reportedly been changed from 1 to 7326680472586200649 about 46 days before the exploit.

4. Investigation Progress​

The public evidence currently supports a token-side logic failure that distorted the OLPC/LABUBU pair's balances and cached reserves. The attack transaction, attacker address, pair address, token contracts, routing pools, and Tornado Cash movement are public, but a final project-level postmortem has not been identified in the reviewed sources.

Recommended response steps for OLPC/LABUBU-style liquidity pools:

  • Publish a final timeline covering the decimalsValue parameter change, ownership changes, pair creation, liquidity events, attack transaction, and post-exploit fund flow.
  • Confirm whether the abnormal burn behavior was intentional tokenomics, a latent logic flaw, or an owner-configured trapdoor.
  • Reconstruct the attack on a BNB Chain fork and convert it into regression tests for burn logic, transfer hooks, reserve updates, sync behavior, and constant-product invariant checks.
  • Add monitoring for pair-level balance/reserve divergence, sudden burns from pool addresses, dead-address transfers, and rapid routes through WBNB/USDT.
  • Warn LPs and integrators when third-party tokens contain owner-set multipliers, burn hooks, transfer fees, or other stateful token behavior that can desynchronize AMM reserves.
  • Coordinate with bridges, analytics providers, and exchanges around the BNB Chain-to-Ethereum path and the 633.4 ETH Tornado Cash deposit.

AUTOSEC.DEV Solution​

The OLPC/LABUBU incident shows why DEX integrations need security coverage beyond router contracts: token hooks, owner-controlled parameters, and reserve synchronization can be enough to turn a single pool into a loss event.

  1. Secure Code Review - The reported OLPC _update path and decimalsValue multiplier created a burn behavior that could desynchronize a PancakeSwap V2 pair's real balances from cached reserves. AUTOSEC.DEV reviews token logic, transfer hooks, burn and fee mechanisms, owner-configurable parameters, and AMM integration assumptions so pool teams can catch reserve-breaking behavior before liquidity is added.
  2. Penetration Testing - This exploit depended on a realistic transaction sequence: a small OLPC input, abnormal pool-side burns, reserve mismatch, LABUBU sweep, and routing through WBNB/USDT. We reproduce attacker workflows on forks to test whether pool math, token transfer behavior, sync boundaries, and exit routes remain safe under adversarial conditions.
  3. Incident Response - Because the attacker bridged value to Ethereum and deposited 633.4 ETH into Tornado Cash, response work must move quickly from root-cause reconstruction into fund-flow tracing. AUTOSEC.DEV supports on-chain evidence collection, attack-path replay, bridge and exchange coordination, disclosure support, and remediation validation.

Reference​