StepHeroNFTs Referral Reentrancy

4. Detailed Root Cause Analysis

The vulnerable sequence is visible in the verified WMRP code:

function _removeLiquidity(address account) internal {
    uint256 liquidity = LPBalanceOf(account);
    (uint256 ethAmount, uint256 tokenAmount) = getReserves();
    uint256 amountETH = liquidity * ethAmount / LPTotalSupply;
    uint256 amountMRP = liquidity * tokenAmount / LPTotalSupply;
    _burnLP(account);
    _safeEthTransfer(account, amountETH);
    _transfer(address(this), account, amountMRP);
    _withdraw(account, amountMRP);
}

This ordering is unsafe because _safeEthTransfer performs an external call before the token-side reserve accounting is finished. The paired buy logic uses current contract reserves when calculating output:

function _buy() internal {
    uint256 buyETHAmount = msg.value - buyFeeAmount;
    uint256 ethContractAmount = getContractEthAmount();
    uint256 balanceOfThis = balanceOf(address(this));
    uint256 buyAmount = buyETHAmount * balanceOfThis / ethContractAmount;
    _transfer(address(this), _msgSender(), buyAmount);
    _withdraw(_msgSender(), buyAmount);
}

During the exploit transaction 0x4353a6d37e95a0844f511f0ea9300ef3081130b24f0cf7a4bd1cae26ec393101, the attacker helper 0x2bd8980a925e6f5a910be8cc0ad1cff663e62d9d receives the ETH leg of _removeLiquidity, immediately reenters WMRP, and performs another buy while the MRP side of the LP burn is still sitting in WMRP reserves. The trace records the original ETH callback into the helper, the reentrant call back into WMRP with 58398821189089608206 wei, and the later transfer path that still pays out the original MRP withdrawal. The balance diff confirms the protocol-side depletion: WMRP and MRP contract-side MRP balances each drop by 6098355549779395839952, while the sender EOA ends the transaction up 17896210904434220483 wei net of gas.

5. Adversary Flow Analysis

The attacker flow is fully permissionless:

1. The EOA 0x132d9bbdbe718365af6cc9e43bac109a9a53b138 sends the exploit transaction and controls helper contract 0x2bd8980a925e6f5a910be8cc0ad1cff663e62d9d.
2. The helper flash-borrows 400 WBNB from Pancake pair 0x0ed7e52944161450477ee417de9cd3a859b14fd0, unwraps it, and buys WMRP exposure.
3. The helper opens the WMRP liquidity path, transfers acquired MRP into WMRP, and adds liquidity with a reserve-derived native amount, creating a temporary LP position.
4. The helper triggers WMRP liquidity removal. When WMRP sends ETH back, the helper fallback uses that callback window to send the received ETH back into WMRP, causing a reentrant _buy() before the original amountMRP has been transferred out.
5. After the reentrant buy, the original _removeLiquidity continues and still transfers the full LP token-side payout to the helper.
6. The helper sells the extracted MRP back through the standard MRP path, wraps enough native value back into WBNB to repay 401.2 WBNB to the pair, and forwards the remaining BNB profit to the EOA.

The end state is visible in the trace and balance diff: the Pancake pair is repaid, the attacker EOA receives value from the helper near the end of the trace, and the net sender gain after gas is 17896210904434220483 wei.

6. Impact & Losses

The exploit drains native-value reserves from the WMRP/MRP system in a single transaction. The measured protocol-side loss is 20066567300062425643 wei of BNB-equivalent reserve value, while the attacker sender EOA realizes 17896210904434220483 wei net profit. The remainder is accounted for by flash-loan fee, protocol fee distribution, and gas. Both WMRP reserve accounting and the linked MRP reserve pool are affected because the exploit extracts excess MRP from WMRP and then monetizes that MRP through the MRP sell path.

7. References

• Seed exploit transaction: 0x4353a6d37e95a0844f511f0ea9300ef3081130b24f0cf7a4bd1cae26ec393101
• Verified WMRP source: WMRP.sol
• Seed trace: trace.cast.log
• Seed balance diff: balance_diff.json
• Seed metadata: metadata.json