UnistreetLaunchpad exploit analysis

DeFiHackLabs reconstructs the on-chain trace and the verified LaunchpadFactoryAuto source, and ties the loss to one design choice in the factory's launch entry point.

The factory's launch() is external payable, takes two opaque byte slices (initCalldata and modifyCalldata) from the caller, and forwards both into Uniswap V4's PositionManager.multicall as the factory itself. posm.multicall self-delegatecalls each entry with msg.sender preserved as the factory, and the factory is the ERC721 owner of every launch's LP-position NFT. There is no validation on the contents of either byte slice before the forwarding.

The attacker passes initCalldata = initializePool(CPOC/WETH) and modifyCalldata = abi.encodeWithSelector(setApprovalForAll.selector, attacker, true). The factory runs setApprovalForAll against the V4 PositionManager as the factory, granting the attacker operator rights over every position the factory custodies, not just the throwaway CPOC launch. PositionManager's modifyLiquidities then accepts a (BURN_POSITION, TAKE_PAIR) action pair against the targeted NFT, which burns the position and routes both underlying currencies back to the attacker. The PoC reproduces the destruction across the seven factory-custodied positions, sweeping the USDC and WETH to the attacker EOA in the same transaction.

DeFiHackLabs records a loss of approximately 17,743.91 USDC and roughly 0.0072 WETH, around $17.75K, in a single transaction. The exploit tx is 0x9583e95d5c88c7966e269197f4b09022f26b7a27ad2c13660dda6774e3136d14 at block 25692311 on Ethereum mainnet, with the attacker EOA at 0xc94e23C58b9b2998eDB7ABC8F99393FEaD985076 and the victim contract LaunchpadFactoryAuto at 0xFB60CD0B36aD4bD839b91767a6Ad9055AB6aD825. The PoC verifies the same loss to the wei against the on-chain trace. Other factory launches' illiquid memecoin positions (such as tokenId 360162 "UNISTREET") were also affected but are not priced here.

This is a third-party-custody bug, not an admin-key compromise. Any user calling launch() becomes an attacker. The mitigation is contained in the same forwarding path: the factory has to constrain initCalldata and modifyCalldata to the action shapes it intends to allow, or restrict posm.multicall self-delegatecall rights so that operator-granting selectors cannot run in the factory's authority. PositionManager's existing hook-system modifyLiquidities does not gate by msg.sender, so the call has to be guarded one layer up.

What would have prevented it: validate that the modifyCalldata selector is on a whitelist before forwarding to the V4 PositionManager, or remove the second write step from the launch path entirely and run the operator grant only after the user has named their recipient.