In the UpdateWeightRunner contract, there are functions called setQuantAMMSwapFeeTake and setQuantAMMUpliftFeeTake, which are protected by admin-only access control. While functions performs its intended job correctly, there is a critical oversight: an admin could mistakenly set the quantAMMSwapFeeTake and quantAMMUpliftFeeTake value to 100% aka 1e18. This creates the potential for unintended disruption of the protocol's functionality, as there is no validation check to prevent the admin from setting this parameter to 100%.
This vulnerability highlights the importance of implementing input validation, even for admin-controlled functions, to avoid accidental misconfiguration that could harm the protocol's usability.
Below is the relevant code from UpdateWeightRunner::setQuantAMMSwapFeeTake:
Below is the relevant code from UpdateWeightRunner::setQuantAMMUpliftFeeTake:
The require statements currently allow the quantAMMSwapFeeTake and quantAMMUpliftFeeTake parameters to be set to 100% (1e18). While this may seem harmless during standard operation, an accidental or incorrect input by the admin could result in severe consequences for the protocol's functionality.
Without a restriction to ensure the parameter remains strictly less than 100%, the oversight could allow:
The fee for swaps and uplifts to be set to an exorbitant level, effectively halting user activity.
Significant disruption of user experience and potential reputational damage to the protocol.
This lack of input validation represents a preventable vulnerability that could have far-reaching implications.
If the quantAMMSwapFeeTake and quantAMMUpliftFeeTake are mistakenly set to 100% 1e18, the following issues may arise:
Exorbitant Fees: Users performing swaps and uplifts would have to pay 100% of of swap and uplift fees.
Protocol Inaccessibility: With users discouraged from performing swaps and uplifts due to excessive fees, the protocol's core functionality could effectively be disabled.
Reputational Damage: Such misconfigurations, even if accidental, could erode user trust in the protocol's reliability and security.
Manual Review
To address this issue, modify the require statement to ensure that the quantAMMSwapFeeTake and quantAMMUpliftFeeTake parameters are strictly less than 100%. The corrected code is shown below:
This change ensures that the quantAMMSwapFeeTake and quantAMMUpliftFeeTake values are always less than 100%, preventing accidental misconfiguration by the admin. It adds a simple but effective layer of input validation that eliminates the possibility of setting a fee value that could disrupt the protocol.
By implementing this fix, the protocol can safeguard its functionality and user experience against such errors, ensuring reliable and uninterrupted operation.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelyhood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
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.