YDT Exploit: Step-by-Step Breakdown and Foundry Simulation
A detailed analysis of the YDT token vulnerability on BSC. This post explains the flawed access control logic, walks through the attacker’s flow, and demonstrates a full exploit simulation using Foundry.
Overview
The YDT token contract on Binance Smart Chain suffered an exploit in which an attacker drained approximately $41,000 worth of USDT by abusing a vulnerable function called proxyTransfer.
🔗 View the transaction on BscScan
Vulnerable Function: proxyTransfer
What Went Wrong
The intent was to restrict calls to proxyTransfer() to only a few internal modules (like taxModule, referralModule, etc.). However:
- The function only checks if the argument
callerModuleis a valid module address. - It does not check if
msg.senderis the actual module contract.
This allows anyone to call the function and pass a whitelisted module address as a parameter, bypassing the intended access control.
This created a critical vulnerability allowing arbitrary transfers from LPs.

Exploit Path Breakdown
The exploit was carried out in three clear steps. Transaction debug is available on Sentio.

Step 1: Abuse proxyTransfer
The attacker pretended to be the taxModule and used proxyTransfer() to pull tokens directly from the Pancake LP into their wallet.
Step 2: Sync the LP
The PancakeSwap liquidity pair was synced to update on-chain reserves and reflect the balance change.
Step 3: Swap to USDT
The attacker swapped the stolen YDT tokens for BSC-USD (a stablecoin), realizing a profit of about $41,000 in a single transaction.
Visual Flow of Funds
Here is a simplified view of the exploit:

Foundry Simulation of the Exploit
The attack was simulated using a local Foundry test on a fork of the Binance Smart Chain.
Steps Performed
- Forked Binance Smart Chain one block before the attack (50273545)
- Called
proxyTransfer()to drain LP tokens - Synced LP state
- Swapped stolen YDT for USDT via PancakeSwap
- Captured logs with
console2to verify balances

Root Cause
The function trusted user input (callerModule) instead of validating the actual caller (msg.sender).
Recommended Fix
Replace the conditional check with strict access control:
Or use a custom onlyModule modifier for better encapsulation.
Key Takeaways
- Always validate
msg.sender, not just function parameters - Never allow proxy-style transfers without strict access controls
- External input validation is critical to secure DeFi contracts
- Consider automated security tools or audits for functions with authority over token movement
Conclusion
The YDT exploit demonstrates how a single incorrect check in access control logic can cause irreversible financial damage. Although the monetary loss was relatively small (~$41k), the reputational harm and trust loss are much harder to recover from.
Projects should carefully review and test any logic that allows token transfers, especially when the transfer authority can be influenced by user-provided parameters.