mVeNFT DOS - can't trigger the vote function #21
Labels
2 (Med Risk)
Assets not at direct risk, but function/availability of the protocol could be impacted or leak value
bug
Something isn't working
downgraded by judge
Judge downgraded the risk level of this issue
M-01
primary issue
Highest quality submission among a set of duplicates
🤖_primary
AI based primary recommendation
🤖_09_group
AI based duplicate group recommendation
satisfactory
satisfies C4 submission criteria; eligible for awards
selected for report
This submission will be included/highlighted in the audit report
Lines of code
https://github.com/code-423n4/2024-09-fenix-finance/blob/main/contracts/core/VoterUpgradeableV2.sol#L485
https://github.com/code-423n4/2024-09-fenix-finance/blob/main/contracts/core/VoterUpgradeableV2.sol#L448
Vulnerability details
Description
The
VoterUpgradeableV2.sol
contract has the functionattachToManagedNFT()
, users use it to delegate their veFNX voting power to a mVeNFT.One of the things this function does after receiving the new voting power is sub-call to
_poke()
and it will update the Last voted Timestamp of the mVeNFTAt this point, the mVeNFT can't trigger the vote function until the next epoch starts due to the
_checkVoteDelay()
.even this check inside the
vote()
doesn't help in this caseHowever, to make things worse this protocol is deployed on Blast transactions are too cheap
malicious users can keep creating new locks every epoch with one wei in
amount
to bypass the zero checkthen at the start of every new epoch (after the start of the voting window) just call
attachToManagedNFT()
By doing this it keeps forcing the mVeNFT to vote to the same gauges.
Impact
DOS attack.
mVeNFT can't invoke the vote function to change the weight of gauges.
mVeNFT can't reset its votes.
Tools Used
Manual Review
Recommended Mitigation Steps
One solution is to not check the vote delay, However, I believe this comes with some trade-off
Assessed type
DoS
The text was updated successfully, but these errors were encountered: