HardhatDeFi
15,000 USDC
View results
Submission Details
Severity: medium
Invalid

Front-Running Leading to Pool ID Collision

Summary

The createContingentPool and batchCreateContingentPool functions of the DIVA protocol are vulnerable to front-running attacks due to a flaw in how the poolId is generated. Attackers can exploit this vulnerability to force legitimate users into failing transactions by intentionally creating duplicate pools.

https://github.com/Cyfrin/2025-01-diva/blob/1b6543768c341c2334cdff87b6dd627ee2f62c89/contracts/src/AaveDIVAWrapperCore.sol#L126

Vulnerability Details

The poolId is derived from the PoolParams passed to the createContingentPool function, which includes parameters such as collateralToken, expiryTime, floor, inflection and other values that define a contingent pool. Within the AaveDIVAWrapper, the user-provided collateralToken is replaced with a wrapped version (wToken) but the underlying PoolParams are otherwise unchanged.

If two users provide identical parameters (including the same original collateralToken), the resulting PoolParams forwarded to DIVA will have the same values for all attributes, including the wrapped collateralToken (wToken). This leads to identical poolIds for both users' requests.

Since the createContingentPool function is permissionless, attackers can detect pending transactions in the mempool, replicate the same parameters and submit their own transaction first causing a duplicate poolId collision.

Impact

Two or more users end up with the same poolId due to identical PoolParams. This results in a rejected transactions for legitimate users

Tools Used

Manual Review

Recommendations

A unique factor such as the user's address (msg.sender) or a random salt value be added to the PoolParams before hashing to create the poolId

Updates

Lead Judging Commences

bube Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.