YDT Token Exploit — Permissionless `proxyTransfer()` Drains the Liquidity Pool

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2025-05-YDTtoken_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/YDTtoken_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/access-control/fake-account-substitution

One-line summary: YDTMainContract.proxyTransfer() authorizes the caller by comparing a user-supplied argument to its module addresses instead of checking msg.sender, so anyone can move YDT out of any account — the attacker empties the PancakeSwap pair's YDT reserve, sync()s it, and swaps a sliver of YDT for ~41,337 USDT of real liquidity.

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder. Full verbose trace: output.txt. Verified vulnerable source: contracts_YDTToken_YDTMainContract.sol.

Key info#

TL;DR#

YDTMainContract is a fee-on-transfer ("tax") token whose sub-modules (tax, referral, deflation, liquidity, LP-tracking) are allowed to move tokens around without re-triggering the tax/referral logic. To support that, the token exposes:

function proxyTransfer(address sender, address recipient, uint256 amount, address callerModule) external {
    require(
        address(taxModule)       == callerModule ||
        address(referralModule)  == callerModule ||
        address(deflationModule) == callerModule ||
        address(liquidityModule) == callerModule ||
        address(lpTrackingModule)== callerModule,
        "Only sub-modules allowed"
    );
    super._transfer(sender, recipient, amount);
}

The require checks the callerModule parameter — a value the caller chooses — against the module addresses. It never checks that msg.sender is one of those modules. The module addresses are public (getXxxModule() view getters, and they appear in every transaction), so any external account can call proxyTransfer(anyAccount, attacker, anyAmount, taxModuleAddress) and pull tokens out of any address that holds YDT.

The attacker uses this to drain the YDT/USDT pair:

1. proxyTransfer(Pair, attacker, pairYDTBalance − 1000e6, taxModule) — moves ~16.17M YDT out of the pair, leaving exactly 1,000 YDT.
2. Pair.sync() — forces the pair to register its now-tiny YDT balance (1,000 YDT) as reserve0, while the USDT reserve (reserve1) stays at ~41,365 USDT. The constant-product invariant is now wildly broken in the attacker's favor.
3. Swap a small amount of the stolen YDT back into the pair through the router — buying out almost the entire 41,365 USDT reserve. Net take: ~41,337 USDT.

Background — what YDT does#

YDTMainContract (source) is an OpenZeppelin-based ERC20 with a modular "tax token" architecture. Its _transfer override routes every (non-owner) transfer through external sub-modules:

• ReferralModule — handleTransfer(...) referral bookkeeping.
• TaxModule — handleTransferTax(...): on a sell (recipient == pair) it charges a 10% tax and sends it to a treasury address addressA (TaxModule.sol:42-49).
• LPHolderTrackingModule — handleTransferLpTracking(...) LP holder accounting.

Because these modules need to move YDT without re-entering the taxed _transfer path (which would recurse), the token gives them a privileged primitive: proxyTransfer, which calls the raw OpenZeppelin super._transfer and bypasses all module logic. The intended caller is, e.g., the tax module, which invokes it as:

// TaxModule.handleTransferTax — the LEGITIMATE call site
ydtToken.proxyTransfer(sender, ydtToken.getAddressA(), tax, address(this));
//                                                            ^^^^^^^^^^^^^ passes itself

i.e., the tax module passes address(this) (its own address) as callerModule. The fatal mistake is that the token trusts that argument as proof of identity.

On-chain facts at the fork block (from the trace):

The vulnerable code#

1. proxyTransfer authorizes by argument, not msg.sender#

contracts_YDTToken_YDTMainContract.sol:245-263:

// 代理转账方法，允许子模块绕过税收和推荐处理
function proxyTransfer(
    address sender,
    address recipient,
    uint256 amount,
    address callerModule          // 调用方模块地址（需为子合约） — caller-supplied!
) external {
    // 校验调用者必须为子合约
    require(
        address(taxModule)        == callerModule ||
        address(referralModule)   == callerModule ||
        address(deflationModule)  == callerModule ||
        address(liquidityModule)  == callerModule ||
        address(lpTrackingModule) == callerModule,
        "Only sub-modules allowed"
    );

    // 直接调用父类转账（跳过子模块逻辑）
    super._transfer(sender, recipient, amount);   // moves anyone's YDT, no allowance
}

The intent (per the comment) is "the caller must be a sub-contract." But the check is module == callerModule, where callerModule is the 4th function argument, fully controlled by whoever calls the function. There is no require(msg.sender == address(taxModule) || ...). super._transfer(sender, recipient, amount) then moves amount YDT from an arbitrary sender with no allowance check.

2. The legitimate call site shows the intended trust model#

contracts_YDTToken_TaxModule.sol:42-50:

if (recipient == pancakePair) {
    // 收取10%的卖出税给A地址
    uint256 tax = amount.mul(100).div(1000);
    uint256 amountAfterTax = amount.sub(tax);
    uint256 senderBalance = ydtToken.balanceOf(sender);
    if (amount > 0 && senderBalance >= amount) {
        console.log("proxyTransfer.start");
        ydtToken.proxyTransfer(sender, ydtToken.getAddressA(), tax, address(this)); // passes itself
        console.log("proxyTransfer.end");
    }
    return amountAfterTax;
}

Note that handleTransferTax itself is properly guarded (onlyAuthorizedCaller, callable only by the token). The developers protected the module but left the privileged primitive proxyTransfer it relies on wide open — anyone can replicate the (…, address(this)) pattern by literally typing the tax module's known address.

3. The owner bypass confirms proxyTransfer is the only "raw move" needed#

contracts_YDTToken_YDTMainContract.sol:206-214 shows that the only entity allowed to do an untaxed/raw move is the owner — every other transfer is taxed. proxyTransfer accidentally hands that same raw-move power to the public.

Root cause — why it was possible#

A standard access-control rule: authenticate the caller, not a value the caller hands you. The classic safe pattern is require(msg.sender == trustedAddress). YDT instead wrote require(trustedAddress == callerModule) where callerModule is an argument. Since the trusted module addresses are public knowledge, the predicate is trivially satisfiable by any attacker, collapsing the access control to "no access control."

Concretely, the bug composes into a critical loss because of three facts:

1. Forgeable authorization. proxyTransfer can be called by anyone who passes a known module address as callerModule.
2. No allowance / no balance ownership check on sender. super._transfer(sender, …) moves tokens out of an arbitrary sender, so the attacker can target the liquidity pool (which holds the bulk of YDT) rather than just their own balance.
3. AMM reserves are derived from balance + sync(). Once the pair's YDT balance is drained, a permissionless Pair.sync() writes the depleted balance into the official reserves, breaking x·y = k. The attacker then trades the stolen YDT back in to extract the untouched USDT reserve.

This is a textbook "approve/transferFrom bypass" elevated to a pool drain because the privileged transfer can name any source account.

Preconditions#

• The YDT token must hold the buggy proxyTransfer and have its sub-module addresses set (they are public via getters and visible in any tx) — true at the fork block.
• A YDT/USDT (or YDT/anything-of-value) pool with meaningful liquidity exists — the pair held ~41,365 USDT.
• The attacker needs no capital, no flash loan, and no prior token holdings — the YDT used to swap out the USDT is itself stolen from the pair via proxyTransfer. (The PoC's reported profit includes ~26.5 USDT that happened to be on the test address on the fork; the exploit-attributable take is the ~41,337 USDT pulled from the pool.)

Step-by-step attack walkthrough (with on-chain numbers from the trace)#

The pair's token0 = YDT (6 dp), token1 = USDT (18 dp), so reserve0 = YDT, reserve1 = USDT. All figures are taken directly from output.txt (Sync/Swap events and balanceOf/getReserves returns).

The pair's USDT reserve fell from 41,365.77 → 28.47 USDT, i.e. 41,337.30 USDT extracted — the realized loss. The attacker still holds ~14.56M stolen YDT (90% of the original pair balance) and the unsold remainder, but its value is near-zero once the pool is destroyed.

Why one tiny YDT sell drains the USDT side#

After step 2 the pair holds only 1,000 YDT against 41,365 USDT. PancakeSwap prices off reserves, so YDT is now valued absurdly high inside the pool. Selling ~1.46M YDT (against a 1,000-YDT reserve) buys essentially the entire USDT reserve: out = (in·9975·reserveUSDT)/(reserveYDT·10000 + in·9975), and with in ≫ reserveYDT the output approaches the full reserveUSDT.

Profit / loss accounting#

Diagrams#

Sequence of the attack#

Pool state evolution#

The flaw inside proxyTransfer#

Remediation#

1. Authenticate msg.sender, never an argument. Remove the callerModule parameter entirely and gate on the actual caller:

   SOLIDITYCopy

   function proxyTransfer(address sender, address recipient, uint256 amount) external {
       require(
           msg.sender == address(taxModule)        ||
           msg.sender == address(referralModule)   ||
           msg.sender == address(deflationModule)  ||
           msg.sender == address(liquidityModule)  ||
           msg.sender == address(lpTrackingModule),
           "Only sub-modules allowed"
       );
       super._transfer(sender, recipient, amount);
   }
   

   This single change makes the forgery impossible — an attacker cannot make msg.sender equal a contract they do not control.

2. Prefer a modifier / role. Introduce an onlyModule modifier or an OpenZeppelin AccessControl MODULE_ROLE and apply it to every privileged primitive, so the pattern is centralized and audited once.

3. Constrain what proxyTransfer may do. Even for genuine modules, consider restricting the sender/recipient set (e.g., only move from the module itself or only the taxed amount) so a single compromised/buggy module cannot move arbitrary third-party balances, including the pool's.

4. Defense-in-depth on AMM interaction. Tokens whose balances can be moved by privileged code should not let that code touch the AMM pair's balance, since sync() will convert any such change into an exploitable reserve mismatch.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has many unrelated PoCs that fail to compile under a whole-project forge test):

_shared/run_poc.sh 2025-05-YDTtoken_exp -vvvvv

• RPC: a BSC archive endpoint is required (fork block 50,273,545). foundry.toml uses https://bsc-mainnet.public.blastapi.io, which serves historical state at that block; most public BSC RPCs prune it and fail with header not found / missing trie node.
• Result: [PASS] testExploit() with Profit in : 41363.845386954430366587.

Expected tail:

Ran 1 test for test/YDTtoken_exp.sol:ContractTest
[PASS] testExploit() (gas: 315535)
Logs:
  ...
  Profit in : 41363.845386954430366587

Suite result: ok. 1 passed; 0 failed; 0 skipped

Bug class: broken access control (caller authorization via a forgeable argument). Vulnerable primitive: YDTMainContract.proxyTransfer(address,address,uint256,address) — selector 0xec22f4c7.

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2025-05-YDTtoken_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: YDTtoken_exp.sol.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "YDT Token Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.