BFB Token Exploit Analysis

On July 8, 2026, the BFB token on BNB Smart Chain was exploited through a flaw in its custom "price-defense" deflationary logic, resulting in the loss of approximately 350.6 WBNB (~$198,000) drained from the PancakeSwap BFB/WBNB liquidity pool. Let's take a closer look at how the attack was carried out.

Attacker (EOA): https://bscscan.com/address/0x3bfa85127c9871d3f74c30e36a618a77f0ae6b0f

Attack Contract: https://bscscan.com/address/0xdd868618956418f77d922fa5d42960fb5fb01b7b

Attack Tx: https://bscscan.com/tx/0xabcf5c5c846595b2d0849f2579b67465ed8d06f3b469cee5e3a57c1f7aed3520

Victim: https://bscscan.com/address/0x719699762fFCC7AadBdCec4E7cf03569E5e99999

Background

BFB is a “deflationary” BEP-20 token whose contract embeds automatic burn mechanics directly into its transfer path. Two burn systems are wired into every transfer through the private _transfer function:

1. _deflPool — a time-based burn that removes a fixed ratio of the LP’s BFB balance once per hour.

2. _priceDeflPool — a price-defense burn intended to “protect” the token’s price: whenever the spot price on the PancakeSwap pool falls more than a threshold below the last recorded high, the contract burns a slice of the BFB held in the pool and calls sync() on the pair.

The design intent of the price-defense mechanism is straightforward tokenomics theater: if the price drops, burn BFB out of the pool to shrink supply-in-reserve and mechanically push the quoted price back up. This is precisely the feature that was weaponized.

Every transfer routes through:

Both transfer() and transferFrom() reach _transfer, so the burn hooks fire on essentially any token movement — including a zero-value self-transfer.

The Vulnerability

The root cause lives in _priceDeflPool:

Price is computed purely from the pair’s spot reserves:

With the relevant parameters set to:

• fallPriceRatio = 500 → a ~5% drop below fallLastPrice arms the burn.

• fallPriceBurnRatio = 500 → 5% of the pool’s BFB balance is burned on each trigger.

• DENOMINATOR = 10000.

BFB derives its "price" straight from the pool's spot reserves (wbnbReserve / bfbReserve), and its price-defense burn edits those same reserves — burning 5% of the pool's BFB and calling sync(), which raises the quoted price while quietly shrinking the AMM invariant k and leaving the pool over-loaded with WBNB against a vanishing BFB reserve. Worse, this destructive burn can be triggered for free and without limit: the !isContract(from) && !isContract(to) guard only inspects the transfer parties, not the caller, so an attacker contract simply calls transferFrom(attackerEOA, attackerEOA, 0) — two EOAs pass the check, and the zero amount also slips past the _bound logic (which only reacts to 1e18 or 5e17). With no cooldown or per-block limit, the attacker can loop this burn hundreds of times in a single transaction, each fire compounding the last, repeatedly forcing the pool to destroy its own BFB reserve at near-zero cost.

The whole exploit ran in a single atomic transaction. The attack contract first flash-borrowed a large amount of liquidity from Lista DAO Moolah (WBNB and BTCB, routed through Venus vTokens) as working capital, with the attacker EOA having pre-approved the contract so that transferFrom(attackerEOA, attackerEOA, 0) would pass the allowance check. It then repeated roughly 151 rounds: in each round it swapped against the BFB/WBNB pair to push the spot price more than 5% below fallLastPrice — the burn branch stays dormant during the swap because the pair is a contract, so the low price is left "primed" while fallLastPrice remains high — and then called transferFrom(attackerEOA, attackerEOA, 0), an EOA→EOA zero-value transfer that passes the !isContract guard and makes _priceDeflPool burn 5% of the pool's BFB and sync() (visible on-chain as the recurring BFB → Null: 0x000…000 transfers interleaved with the swaps). Since each burn scales the reserve by ~0.95, after ~151 rounds 0.95^151 ≈ 4e-4 drove the pool's BFB reserve to about 0.04% of its starting value while the WBNB reserve stayed intact — leaving abundant WBNB backing a near-zero BFB reserve. At that point constant-product math meant a dust-sized BFB input could extract nearly all the pool's WBNB, so the attacker made the final swap, repaid the flash loan, and exited with ≈ 350.6 WBNB (~$198,956) for a transaction fee of about $0.39.

Conclusion

The BFB exploit is a textbook example of a token's own "feature" becoming its fatal flaw. A price-defense routine that (a) priced itself off manipulable spot reserves, (b) burned liquidity-pool reserves and re-synced on demand, (c) could be triggered for free by any contract via a zero-value EOA→EOA transferFrom, and (d) had no rate limit, allowed an attacker to loop ~151 burns in a single flash-loan-funded transaction, collapse the BFB reserve toward zero, and swap dust BFB for the pool's entire WBNB — walking away with roughly $198,000 for less than a dollar in gas.