Attacker can front-fun redeeming positions

[hats-bug-reporter[bot]]

Github username: -- Twitter username: -- Submission hash (on-chain): 0x45f04ce44a8b5cb2c8ca9ce8d7d50680cbd2f5221a66b3467e577fd9133630ff Severity: high

Description: Description\ The redeemPositions function allows users to redeem positions and withdraw collateral tokens. Without proper front-running protection, an attacker could monitor the mempool and attempt to front-run legitimate users by executing redemptions just before their transaction is confirmed. This could result in an attacker redeeming the same market positions, potentially draining funds or reducing the claimable amount for the honest user.

[contracts/src/Router.sol]
143     function redeemPositions(IERC20 collateralToken, Market market, uint256[] calldata outcomeIndexes) public {
144         bytes32 parentCollectionId = market.parentCollectionId();
145         uint256 initialBalance;
146 
147         if (parentCollectionId == bytes32(0)) {
148             initialBalance = collateralToken.balanceOf(address(this));
149         }
150 
151         _redeemPositions(collateralToken, market, outcomeIndexes);
152 
153         if (parentCollectionId == bytes32(0)) {
154             uint256 finalBalance = collateralToken.balanceOf(address(this));
155 
156             if (finalBalance > initialBalance) {
157                 collateralToken.transfer(msg.sender, finalBalance - initialBalance);
158             }
159         }
160     }

Attack Scenario\ In a high-value market, suppose a user initiates a transaction to redeem their positions. Before their transaction is confirmed, an attacker could observe this in the mempool and quickly submit their own redemption transaction with higher gas fees. The attacker’s transaction could be prioritized and processed first, allowing them to redeem positions for the same outcomes. This could deplete the available collateral or market positions, leaving the original user with fewer or no tokens to redeem.

Attachments

1. Proof of Concept (PoC) File\

   • User A submits a transaction to redeem 100 collateral tokens from a market.
   • Attacker B monitors the mempool and sees User A's transaction.
   • Attacker B submits the same redemption for the same outcome index but with a higher gas fee.
   • Attacker B’s transaction is processed first, reducing the available collateral in the market.
   • User A’s transaction is processed later, resulting in fewer tokens available for redemption.

2. Revised Code File (Optional)\

Use time delays or commit-reveal schemes to prevent front-running attacks, especially in high-value markets.

[greenlucid]

Then, this "victim" has spent less gas than the "attacker" into redeeming his own winning shares, so where's the loss? _redeemPositions will fully redeem the shares of the passed outcomeIndexes, you cannot redeem partially

[clesaege]

This could deplete the available collateral or market positions, leaving the original user with fewer or no tokens to redeem.

This is the point of the report which is incorrect, positions are always fully collateralized.