Skip to main content
• 6 min read

BYToken Public Maintenance Function
Exploit: BY/WBNB Liquidity Drained for 146.6 BNB

BYToken on BNB Chain was reported exploited after a public maintenance function was abused to drain BY/WBNB liquidity, with TenArmor estimating about $88.4K in losses and ClaraHacks tracing roughly 146.601 BNB gained by the attacker.

AUTOSEC.DEVAUTOSEC.DEV
BYToken Public Maintenance Function Exploit: BY/WBNB Liquidity Drained for 146.6 BNB
  • Incident Date: June 5, 2026
  • Target: BYToken / BY-WBNB liquidity on BNB Chain
  • Target Overview: BYToken is a BNB Chain token with liquidity paired against WBNB. Public reporting described the exploit as abuse of a public BYToken maintenance function, not as a BNB Chain consensus issue or a PancakeSwap/WBNB protocol failure.
  • Reported Exploit Transaction: 0xe31c681eee764fb94b1b6bda3bbb0e4f25acb129c19040b9f58ad30541980979
  • Reported Block: 102329719
  • Total Loss: TenArmor reported approximately $88.4K in losses; ClaraHacks reported that the attacker gained about 146.601364371618057369 BNB.
  • Affected Liquidity: BY/WBNB liquidity on BSC.
  • Recovery Status: No public final post-mortem, confirmed recovery, reimbursement plan, or completed patch disclosure had been identified in the reviewed sources at the time of writing.
  • Attack Vector: Public Maintenance Function Abuse / Missing or Insufficient Access Control / Token Accounting Manipulation / DEX Liquidity Drain

Incident Review & Technical Details​

1. Attack Path​

  1. A Maintenance Function Was Publicly Reachable: ClaraHacks described the root path as a public BYToken maintenance function on BSC that was abused as an exploit. Based on that description, the risky surface was not a normal user transfer or swap alone, but a token-side operational function that could affect market state.
  2. The Function Was Used Against BY/WBNB Liquidity: The attacker reportedly used the function in a way that allowed value to be extracted from the BY/WBNB pool. This is consistent with a token-contract failure that changes balances, fees, reserves, exemptions, or transfer-side behavior before routing value through DEX liquidity.
  3. Liquidity Was Drained Into BNB: ClaraHacks reported that the attacker gained approximately 146.601364371618057369 BNB from the drain.
  4. Public Loss Estimates Were Framed in USD and BNB: TenArmor's alert estimated the incident at roughly $88.4K, while ClaraHacks provided a BNB-denominated gain figure tied to the same transaction.
  5. The Exploit Was Concentrated in One Reported Transaction: Both public alerts pointed to transaction 0xe31c681eee764fb94b1b6bda3bbb0e4f25acb129c19040b9f58ad30541980979, with ClaraHacks also identifying block 102329719.
  6. Final Contract-Level Details Remain Unconfirmed: Public alerts did not yet provide the exact function name, affected contract address, patch transaction, privileged-role history, or a project-owned post-mortem. Those gaps should remain explicit until the BYToken team or independent trace reports publish a complete breakdown.

2. Impact Scope​

  • Direct Economic Impact: Public reporting placed the loss at about $88.4K, or roughly 146.601 BNB gained by the attacker.
  • Affected Network: BNB Chain.
  • Affected Assets: BY token liquidity paired with WBNB, with value realized as BNB.
  • Affected Participants: Liquidity providers and token holders exposed to the BY/WBNB pool were the practical victims if pool liquidity or market price was impaired.
  • Unaffected Components: Reviewed sources did not identify a BNB Chain consensus failure, WBNB contract vulnerability, or DEX router vulnerability. The available evidence points to BYToken-side logic.
  • Disclosure Gap: No official final disclosure was available in the reviewed material, so the precise vulnerable code path, residual risk, and remediation status remain source-dependent.

3. Root Cause Assessment​

This incident is best understood as a token-side maintenance-function control failure. Maintenance functions are often added for operational reasons: updating fees, syncing liquidity behavior, managing exclusions, changing pair parameters, rescue operations, or handling edge cases. If such a function is public, weakly gated, or able to change economic state without strict invariants, it can become a direct route into pool liquidity.

Key risk patterns to examine:

  • Operational Logic Became an Attack Surface: Functions labeled as maintenance are still part of the public contract interface unless they are strongly access-controlled and invariant-tested.
  • Access Control May Have Been Missing or Too Weak: A maintenance path that can affect liquidity-sensitive state should not be callable by arbitrary users.
  • Token Accounting Can Break AMM Assumptions: If a token function can alter balances, fees, transfer behavior, exemptions, or reserve-facing accounting unexpectedly, AMM pools may be forced into an exploitable state.
  • Liquidity Drain Can Follow a Single State Perturbation: The attacker may not need repeated transactions if one public function call creates a profitable imbalance that can be monetized immediately.
  • No Public Patch Signal Was Available: Without a confirmed pause, role change, code migration, or liquidity migration, similar public functions should be treated as high risk until reviewed.

The core invariant should have been strict: no public maintenance function should be able to change BYToken economic state in a way that extracts, misprices, or redirects BY/WBNB liquidity without authorization, bounded parameters, event-rich monitoring, and tests against AMM-drain scenarios.

4. Mitigation and Response​

Recommended actions for BYToken-style token projects, liquidity managers, and monitoring teams:

  • Immediately identify the exact callable maintenance function used in the reported transaction and verify whether it remains reachable.
  • Pause, disable, or restrict any function that can alter token balances, pair behavior, swap routing, fee exemptions, reserve-facing state, or liquidity-sensitive accounting.
  • Add explicit access control to operational functions, preferably behind a multi-signature wallet and timelock for non-emergency changes.
  • Add hard parameter bounds and state invariants so maintenance calls cannot create pool imbalance, redirect fees, mint or burn unexpectedly, or bypass normal transfer accounting.
  • Review all public and external functions, not only owner-only functions, for hidden economic side effects.
  • Reconstruct the exploit on a fork from transaction 0xe31c681eee764fb94b1b6bda3bbb0e4f25acb129c19040b9f58ad30541980979 and convert the trace into regression tests.
  • Monitor abnormal BY/WBNB reserve changes, large swaps after maintenance calls, sudden WBNB outflows, role changes, and interactions from new attacker-funded addresses.
  • Publish a final post-mortem with the affected contract address, vulnerable function name, transaction sequence, confirmed loss, patch status, and liquidity-holder remediation plan.
  • If liquidity remains in an affected pair, coordinate a verified migration or protective withdrawal process with clear user-facing warnings.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The BYToken incident shows why token security reviews must treat "maintenance" code as production-critical economic logic. A helper function that looks operational can become the whole exploit if it can touch liquidity-sensitive state.

  1. Token Logic & Access-Control Audit: AUTOSEC.DEV reviews public/external functions, fee logic, pair handling, mint/burn controls, exclusion lists, rescue functions, owner privileges, and maintenance paths.
  2. AMM Interaction & Invariant Testing: We build fork tests and simulations for pool imbalance, reserve manipulation, transfer-tax edge cases, public function abuse, and single-transaction liquidity drains.
  3. On-Chain Monitoring & Emergency Controls: We design alerts for suspicious maintenance calls, abnormal reserve movement, WBNB outflows, ownership changes, and high-impact state transitions.
  4. Incident Response (IR): AUTOSEC.DEV supports exploit reconstruction, fund-flow tracing, emergency pause and migration planning, public communications, and post-incident hardening.

Service Content​

Reference​