This issue requires knowledge of Uniswap v4 hooks, each time a pool operation happens these hooks may be called depending on the hook's config. Here is a nice resource on these hooks. Find the image below showing just the hook before and after modifying liquidity.
The pool's reward distribution occurs during each liquidity operation through the beforeAddLiquidity and beforeRemoveLiquidity hooks. The Uniswap pool's donate mechanism is used, which distributes rewards to in-range LPs at the current slot0.tick.
The problem with this design is that rewards accrued over a certain period are distributed to the current in-range position, regardless of which positions provided active liquidity during the accrual period.
Weaponizing it
This can be exploited by an attacker who performs the following steps (can be done in a single transaction):
1. Some time has passed and rewards have been accumulated, but not distributed.
2. Attacker makes a swap to move the tick to a predefined tick where their position provides liquidity in a small adjacent tick range.
3. Triggers the reward distribution mechanism by collecting fees (e.g., modifying liquidity with a 0 liquidity delta, which triggers the beforeRemoveLiquidity hook).
4. His position would accrue most of the fees because of the super tight range it has provided liquidity.
Swaps back to move the tick to its original value.
Conclusion
This finding would earn you 5661 OP, which is super low because at the time OP is down bad. But still, requires a deep Uniswap knowledge, so make sure to read on that!
