AlpsCon exploit analysis

AlpsCon's AI Trade Hub on BNB Chain puts its deposit and reward functions behind a whitelist, and that whitelist still carried 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266. That is the canonical Hardhat and Anvil default account #0, and its private key is published in Hardhat's documentation. The hub treated presence in an allowlist as proof of who was calling. DeFiHackLabs records the mechanism, and ships a proof of concept that replays it against a fork of the chain.

An allowlist is not an identity

The deposit call purchaseServiceCredits and the reward calls migrate and claimServiceResults each require the caller to be on an onlyVerified whitelist. The proof of concept calls that whitelist directly at the block before the attack and reads isInWhiteList as true for the Hardhat account and false for a fresh address. The gate works exactly as designed. It is the contents of the list that leave nothing behind.

Because the private key is public, EIP-7702 removes even that. An EIP-7702 authorization is a signature that redirects an account to contract code while leaving the account's own address in place. Producing a valid one for this account needs no stolen key, since the key needed is the one in the manual. The attacker signed the delegation and the rest of the exploit ran as 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266, passing every check along the way.

The attack transaction at block 128,315,188 shows the shape of this directly. It is an EIP-7702 (type 4) transaction sent from the attacker's own address to 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266, so the recipient is the well-known account itself, running the attacker's code through the delegation.

A new deposit collected the whole history

The accounting defect underneath is separate from the access control, and the attack needed both. The hubs are versioned, V6 through V9, and each version pulls the balances of the one before it forward through migrate. claimServiceResults then pays those imported balances against the version's already accumulated profitPerShare, while the depositor's own entryProfitPerShare is still zero. For a fresh deposit the difference between the two should be close to zero. Measured from zero instead, it is the full accumulated reward history of every version that came before.

A deposit made earlier in the same transaction is therefore paid as though it had been staked through that whole history.

The sequence

1. Flash-borrow 1,027,990 USDC from Aave V3.
2. Buy ALPS through the project's own router.
3. Deposit into the still-open V6 hub.
4. Call migrate() to import the stake forward, then claimServiceResults() on V9.
5. Withdraw, sell the ALPS back into USDC, and repay the loan.

DeFiHackLabs records about 152.8K USDC drained from the hub reward pools, of which the attacker's address received 152,295.3625 USDC before gas, with the Aave loan of 1,027,990 USDC repaid in full at 1,028,503.995 USDC. The proof of concept reconstructs the dominant V9 leg at 129,775.6074 USDC and attributes the remaining 22,519.75 USDC to a cascade through the V7 and V8 hubs inside the same call, which an equivalent standalone call does not reproduce.

The chain supports the reconstruction. The transaction moved 129,775.607410 USDC from the delegated account to the attacker's address, the figure the reconstruction lands on exactly, plus 20,553.69 and 1,966.07 USDC sent directly from the V8 and V7 hubs. Together the three transfers make up the 152,295.36 USDC total.

Where the guard was missing

Two checks would have closed this on their own. A whitelist entry should not be an account whose key is public knowledge, and a reward claim should be bounded by the period the depositor actually participated in, which is what entryProfitPerShare was there to do but was read as zero for a fresh position.

GaslessReservoirEnabler also failed on the contents of a whitelist: its moduleWhitelist included the live WETH token, so any caller could route transferFrom calldata through the contract and drain wallets with standing WETH approvals to it. Different defect, same reliance on a list that was never the control it was treated as.