Unverified BSC Contract Access Control Swap Vulnerability

Notice: This page is a freshly imported case study from an original repository. While the original content had a similar format, some sections may not have been fully completed. Please help fill in any empty sections or any missing information you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Binance Security Image

An unverified smart contract was deployed on the Binance Smart Chain (BSC) at address 0x16D7..., containing a critical vulnerability in its 0xf8c03cc4() function. Due to a lack of proper access controls, the function could be called by anyone to initiate token swaps using assets from users who had granted the contract prior approvals. The attacker exploited this flaw by draining tokens—such as WBNB and TA—from unsuspecting users, swapping them through malicious or manipulated liquidity pools at inflated rates. This led to losses totaling approximately $615,000, with notable attack transactions including 0x960f, 0xc374, and 0xb92d. The victims were largely TrustaLabs token holders, and the exploit was reported by both HackenClub and TenArmor. No fund recovery has been reported, and the contract remains a cautionary example of the risks of approving unverified contracts.

About Unverified Contract

An unverified contract was created on July 21st, 2025. Limited information is known about this contract or it's creator.

The Reality

The smart contract contained a vulnerability which allowed tokens to be drained from users who had granted the contract permissions.

What Happened

An unverified smart contract on BSC exploited a critical access control flaw to drain approximately $615,000 from users who had unknowingly approved it to spend their tokens.

Key Event Timeline - Unverified BSC Contract Access Control Swap Vulnerability

Date	Event	Description
July 21st, 2025 9:57:38 PM MDT	Smart Contract First Created	The unverified smart contract is first launched on the Binance Smart Chain.
July 23rd, 2025 2:15:02 AM MDT	First Attack Transaction	The first attack transaction, as later reported by TenArmor.
July 23rd, 2025 2:18:11 AM MDT	Second Attack Transaction	The second attack transaction, as later reported by TenArmor.
July 23rd, 2025 2:39:04 AM MDT	Third Attack Transaction	The third and final attack transaction which is reported by TenArmor.
July 23rd, 2025 5:48:00 AM MDT	HackenClub Tweet Posted	HackenClub posts a detailed analysis of the attack transactions with further detailed information.
July 23rd, 2025 10:50:00 AM MDT	TenArmorAlert Tweet Posted	TenArmor posts an alert tweet about the compromise, with some limited details about the exploit.

Technical Details

The exploit targeting the Binance Smart Chain (BSC) involves a smart contract at address 0x16D7..., which lacks adequate access control on a specific function: 0xf8c03cc4(). This function was improperly exposed, allowing anyone to invoke it and trigger token swaps on behalf of users who had previously approved the contract to spend their tokens.

The attacker exploited this vulnerability by identifying externally owned accounts (EOAs) that had given token approvals to the contract—likely in anticipation of a legitimate service or interaction. Using the 0xf8c03cc4() function, the attacker repeatedly drained these tokens by swapping them through manipulated or malicious liquidity pools (e.g., fake PancakeSwap pools) with inflated exchange rates, maximizing the value extracted per transaction. One example involved draining Wrapped BNB (WBNB), while another involved TA tokens, both via pools under the attacker's control.

This attack affected a wide range of TrustaLabs token holders and led to an estimated total loss of around $615,000. The victims were primarily users who had unknowingly granted token approvals to the vulnerable contract.

Attack Transactions: 0x960f3fbbe53b80bc306a64ad33d16dd73bfc164c787114d57cfe0080b5c10b08 0xc3745e4f08bcccaf3efe584a9408d77d675cb996151735c8deaff34997c3a10e 0xb92d3594b818470cc3f6c03eff4a9c5704d87df9749557336545c39c7b2bfed9

Total Amount Lost

Hackenclub reported the losses as $615k. They reported that loss transactions include 0x960f for $280k, and 0xc374 for $335k. TenArmor reported the loss total as $610k, from 3 transactions.

The total amount lost has been estimated at $612,000 USD.

Immediate Reactions

Reports about the exploit were put together and published by HackenClub and TenArmor.

Ultimate Outcome

It appears that the vulnerable contract caused damage far beyond it's initial purpose. It's unclear if any recovery was made or any actions were undertaken to resolve the vulnerability.

Total Amount Recovered

There is no indication that any funds were recovered from the incident.

There do not appear to have been any funds recovered in this case.

Ongoing Developments

Investigation may continue for affected users.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.