The _performMultiDexSwap function does not verify that the last token in the swap path is WETH before proceeding with reward distribution. This flaw could cause the reward distribution function to add the wrong amount of WETH in the receiveWethReward, potentially leading to incorrect reward calculations and distribution.
The vulnerability exists in the following code in the convertAccumulatedFeesToWeth function:
https://github.com/Cyfrin/2025-01-zaros-part-2/blob/main/src/market-making/branches/FeeDistributionBranch.sol#L188-L220
In both the else if and else branches, the code ensures that tokenOut will always be WETH (tokenOut: ctx.weth). However, the _performMultiDexSwap function does not verify if the last token (tokenOut) in the swap path is WETH before swaps (tokenOut: assets[i + 1]).
https://github.com/Cyfrin/2025-01-zaros-part-2/blob/main/src/market-making/branches/FeeDistributionBranch.sol#L428
However, after performing the swaps, the system assumes the final output token is WETH, and the receiveWethRewar is calculated based on this assumption but the address does not receive WETH. Also, the receiveWethReward assumes the self.receivedFees has been fully swapped to weth and remove the asset.
https://github.com/Cyfrin/2025-01-zaros-part-2/blob/main/src/market-making/leaves/Market.sol#L504-L525
Incorrect receiveWethReward: If the final token in the swap path is not WETH, the system will incorrectly adding WETH rewards without actually receving the WETH. Leading to imbalances in reward distribution.
Manual code review
Add a check for WETH in final swap path token in the _performMultiDexSwap function
Ensure the fee has been swapped to WETH before self.receivedFees.remove(asset); in receiveWethReward function
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.