BBX Token Hack Analysis

BBX Token Hack Analysis

Overview:

On March 20, 2025, BBX Token (@BBX) on the BNB Smart Chain (BSC) suffered a liquidity pool manipulation attack, resulting in a loss of approximately $12,000. The attacker exploited the BBXToken contract’s transfer mechanics, specifically its burn mechanism and sync function, to manipulate PancakeSwap’s liquidity pool reserves and extract value.

This vulnerability is an example of OWASP SC02: Price Oracle Manipulation

Smart Contract Hack Overview:

• Attack Transaction: 0x0dd48
• Victim Contract: 0x60514
• Attacker’s Address: 0x8AEa7
• Exploit Contract: 0x0489E
• OWASP SC Top 10: SC02: Price Oracle Manipulation

Decoding the Smart Contract Vulnerability:

• The root cause of the exploit arises from the BBXToken contract’s _transfer function, which burns liquidity pool tokens by transferring them to the dead address (0xdead) before calling sync(). This operation artificially alters the pool’s reserves, creating an imbalance that the attacker exploited.
• The _transfer() function calls the burn mechanism even if the actual transfer amount is zero.

• This code removes tokens from the liquidity pool and updates the pool’s reserve balance using sync(). The burn operation reduces the available supply in the pool, making the price calculation incorrect.
• The attacker repeatedly called the transfer function (252 times), forcing the liquidity pool to burn tokens and update its reserves.
• The contract does check lastBurnTime to prevent continuous burns using: if (block.timestamp >= lastBurnTime + lastBurnGapTime). However, this check does not prevent manipulation within the same block. The attacker spammed transactions, resetting the pool’s reserves over multiple transactions in a short time.
• This action depleted the pair’s balance and made the pool price highly skewed.

• Once the pool was sufficiently imbalanced, the attacker approved and executed a swap via PancakeRouter. Using the manipulated reserves, then they extracted tokens at a favorable rate.
• Then attacker transferred all stolen funds to their own wallet and using Tornado Cash obfuscated the stolen funds.

Mitigation and Best Practices:

• Modify the _transfer() function to prevent forced LP token burns that deplete liquidity. Instead, implement controlled burns based on predefined conditions, such as a time lock or governance approval.
• Require a cooldown period between sync() calls to prevent attackers from continuously resetting reserves. Additionally, verify that sync operations align with valid trading activity before execution.
• Before allowing token transfers that impact the LP, check that the liquidity pool maintains a minimum balance. Reject transactions that would reduce reserves below a safe threshold.
• Ensure swap calculations use the actual token balance after transfers, not pre-transfer values. This prevents scenarios where attackers manipulate token reserves through forced burns.
• To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
• Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord