deposit_For function in VotingEscrow.sol accepts NFTs of all types including locked and managed
Summary
The deposit_For function in the VotingEscrow.sol contract incorrectly accepts NFTs of all types (normal, locked, and managed) without proper restrictions. This oversight allows unauthorized modifications to locked and managed NFTs, potentially disrupting the intended voting power mechanics and reward distribution system.
Vulnerability Detail
The deposit_for function is designed to allow users to deposit additional tokens for a given NFT, increasing its locked amount and potentially its voting power. However, the function lacks proper checks to differentiate between normal, locked, and managed NFTs:
According to the current design of the protocol, anyone can call deposit_For against a normal NFT, no one should be able to call deposit_For against a locked NFT and finally only RewardsDistributorV2.claim function is allowed to call deposit_For function against a managed NFT for processing rebase rewards.
The vulnerability stems from the following issues:
No check is performed to verify if the NFT is locked or managed.
The function allows anyone to call it for any existing NFT, regardless of its type.
For locked NFTs, this could lead to an increase in voting power, which should not be possible.
For managed NFTs, this bypasses the intended mechanism where only RewardsDistributorV2.claim should modify their balance.
But deposit_For function was found to accept NFT of all types (normal, locked, managed) without any restriction.
Impact
The ability to modify managed NFTs directly breaks the protocol's design, where only the RewardsDistributorV2 should handle these operations. Moreover, users can increase the voting power of locked NFTs, which should not participate in voting.
0xShoonya
Medium
deposit_For
function inVotingEscrow.sol
accepts NFTs of all types including locked and managedSummary
The
deposit_For
function in theVotingEscrow.sol
contract incorrectly acceptsNFTs
of all types (normal, locked, and managed) without proper restrictions. This oversight allows unauthorized modifications to locked and managed NFTs, potentially disrupting the intended voting power mechanics and reward distribution system.Vulnerability Detail
The
deposit_for
function is designed to allow users to deposit additional tokens for a givenNFT
, increasing its locked amount and potentially its voting power. However, the function lacks proper checks to differentiate betweennormal
,locked
, andmanaged
NFTs:According to the current design of the protocol, anyone can call
deposit_For
against anormal NFT
, no one should be able to calldeposit_For
against alocked NFT
and finally onlyRewardsDistributorV2.claim
function is allowed to calldeposit_For
function against amanaged NFT
for processing rebase rewards.The vulnerability stems from the following issues:
RewardsDistributorV2.claim
should modify their balance.But
deposit_For
function was found to accept NFT of all types (normal, locked, managed) without any restriction.Impact
The ability to modify managed NFTs directly breaks the protocol's design, where only the
RewardsDistributorV2
should handle these operations. Moreover, users can increase the voting power of locked NFTs, which should not participate in voting.Code Snippet
https://github.com/sherlock-audit/2024-06-velocimeter/blob/63818925987a5115a80eff4bd12578146a844cfd/v4-contracts/contracts/VotingEscrow.sol#L826-L833
Tool used
Manual Review
Recommendation
Add a type check for NFTs in the
deposit_for
function:Duplicate of #558