Skip to main content
• 6 min read

ATM Token transferFrom Hidden
Swap Exploit: BSC Token Drained for $243.5K

ATM Token on BNB Chain was reported exploited for roughly $243.5K after an attacker abused token-side transferFrom logic that repeatedly triggered a hidden ATM-to-BSC-USD swap path.

AUTOSEC.DEVAUTOSEC.DEV
ATM Token transferFrom Hidden Swap Exploit: BSC Token Drained for $243.5K
  • Incident Date: June 4, 2026
  • Target: ATM Token on BNB Chain
  • Target Overview: ATM is a token deployed on BNB Chain. Public reporting described the incident as a token-side exploit involving custom transferFrom() behavior, not as a BNB Chain consensus issue or a PancakeSwap router vulnerability.
  • Reported Exploit Transaction: 0x37b90a337075cd2feea93b12780abe9f953dad476e1c1418a02447aaa6dcfd86
  • Total Loss: Approximately $243,500.
  • Affected Assets: ATM token liquidity and BSC-USD-denominated value on BNB Chain.
  • Recovery Status: No public final post-mortem, confirmed recovery, reimbursement plan, or complete patch disclosure had been identified in the reviewed sources at the time of writing.
  • Attack Vector: Hidden Swap Logic / transferFrom() Abuse / Token Accounting Manipulation / Repeated Internal Swap / DEX Liquidity Drain

Incident Review & Technical Details​

1. Attack Path​

  1. A Token Transfer Hook Became the Attack Surface: Public coverage described the exploit as abuse of custom transferFrom() logic in the ATM token contract. The relevant behavior was not a normal BNB Chain failure, but token-side logic that executed additional economic actions during transfer handling.
  2. A Hidden Swap Path Was Triggered: Technical reporting attributed the loss to logic that could swap a portion of ATM into BSC-USD during transferFrom(). In normal design terms, this means a token transfer path was also able to move value through a swap route.
  3. The Attacker Repeated the Trigger: By repeatedly invoking the vulnerable path, the attacker could force the contract-side swap behavior more than intended and convert the accounting side effect into extractable value.
  4. Liquidity Was Drained Through One Reported Transaction: Public alerts traced the malicious activity to transaction 0x37b90a337075cd2feea93b12780abe9f953dad476e1c1418a02447aaa6dcfd86.
  5. Loss Estimates Converged Around $243.5K: TenArmor, Phemex, and WOOFUN-linked reporting all described the incident as causing roughly $243,500 in losses.
  6. Final Contract-Level Details Remain Unconfirmed: The reviewed public sources did not provide a complete project-owned post-mortem, vulnerable contract address, patched code diff, attacker funding path, or full fund-flow recovery status.

2. Impact Scope​

  • Direct Economic Impact: Public reporting placed the loss at approximately $243,500.
  • Affected Network: BNB Chain.
  • Affected Asset Surface: ATM token liquidity and BSC-USD swap exposure.
  • Affected Participants: ATM token holders and liquidity providers were exposed to the practical market damage if pool liquidity or token price was impaired.
  • Unaffected Components: Reviewed sources did not identify a BNB Chain consensus failure, WBNB or BSC-USD contract vulnerability, or DEX router exploit. The available evidence points to ATM token-side logic.
  • Disclosure Gap: Without an official final disclosure, the exact reachable function path, contract addresses, patch status, and residual risk should be treated as unresolved.

3. Root Cause Assessment​

This incident is best understood as a token accounting and transfer-hook design failure. A token's transferFrom() path is often assumed to be a simple allowance-checked transfer, but many BNB Chain tokens embed fee logic, auto-swap behavior, liquidity management, exemption handling, and treasury routing inside transfer functions. If those side effects are not tightly bounded, an attacker can turn an ordinary transfer interface into a swap engine.

Key risk patterns to examine:

  • Transfer Logic Did More Than Transfer: A transferFrom() path that can initiate swaps becomes a high-risk economic primitive, not just ERC-20 plumbing.
  • Internal Swap Conditions May Have Been Reentrant or Repeatable: If the swap trigger can be reached repeatedly without strong state guards, cooldowns, amount caps, or sender restrictions, the attacker can manufacture unintended swap volume.
  • Token Accounting Can Break AMM Assumptions: Automated swaps, fee-on-transfer behavior, balance mutation, or reserve-facing side effects can desynchronize expectations between the token and liquidity pools.
  • Loss Can Occur Without a Router Bug: The DEX may behave correctly while the token contract supplies attacker-controlled or attacker-amplified swap behavior.
  • Hidden Economic Behavior Reduces Monitoring Quality: If swap logic is embedded in transfer paths, defenders may miss the relationship between benign-looking transfer calls and liquidity-draining effects.

The core invariant should have been strict: transferFrom() must not allow arbitrary users to repeatedly trigger value-moving swap logic that can drain token or stablecoin liquidity, bypass accounting limits, or create market-moving side effects outside intended operational bounds.

4. Mitigation and Response​

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

  • Identify the exact transferFrom() branch and internal swap condition used in the reported transaction.
  • Disable or pause any transfer-triggered swap logic until it is reviewed on a fork against the exploit transaction.
  • Add hard caps on automatic swap size, frequency, and caller eligibility, with explicit protection against repeated trigger loops.
  • Separate user transfers from liquidity-management operations where possible; privileged or scheduled liquidity maintenance should not hide inside routine transfer functions.
  • Add state guards so transfer hooks cannot recursively or repeatedly perform economic actions within one attacker-controlled sequence.
  • Review fee-on-transfer, auto-liquidity, treasury swap, exemption, blacklist, and allowance paths for unintended AMM reserve effects.
  • Build regression tests from transaction 0x37b90a337075cd2feea93b12780abe9f953dad476e1c1418a02447aaa6dcfd86, including repeated transferFrom() calls, low-liquidity pool conditions, and stablecoin conversion loops.
  • Monitor abnormal internal swaps initiated from token contracts, sudden BSC-USD outflows, repeated allowance-driven transfers, and large reserve changes after token-side calls.
  • Publish a final post-mortem with affected contract addresses, vulnerable function names, confirmed loss, attacker fund flow, patch status, and remediation guidance for holders and liquidity providers.

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

The ATM Token incident shows why token audits must treat transfer functions as production-critical economic logic. A transfer path that quietly swaps assets can become the entire exploit surface if attackers can trigger it repeatedly.

  1. Token Transfer & Accounting Audit: AUTOSEC.DEV reviews transfer(), transferFrom(), allowance handling, fee logic, auto-swap code, liquidity management, exemptions, and reserve-facing side effects.
  2. AMM Interaction & Fork Simulation: We build simulations for fee-on-transfer edge cases, repeated swap triggers, reserve imbalance, liquidity-drain sequences, and attacker-controlled allowance flows.
  3. Invariant Testing & Runtime Monitoring: We define invariants around transfer purity, swap limits, reserve movement, internal swap frequency, and stablecoin outflows, then convert them into tests and alerts.
  4. Incident Response (IR): AUTOSEC.DEV supports exploit reconstruction, fund-flow tracing, emergency pause or migration planning, public communications, and post-incident hardening.

Service Content​

Reference​