Submitted by Kumpa, also found by SecureZeroX and unforgiven
Since _maxTime needs to be manually input in the constructor with no other ways of changing it, if the owner inputs the _maxTime that is higher than the capacity of each vaults of veTokens, it will cause IVoteEscrow(escrow).increase_unlock_time(_value); to get rejected.
In the mild case when a user initially locks the asset during depositing, the contract will simply revert the transaction.
In the severe case when a user does not lock the asset during depositing, the asset will end up locked in the contract since noone will be able to succesfully call lockVeAsset. This will cause the asset to be locked up with no way of withdrawing it. Even though a user will still get benefits from the minted reward, a contract will not be able to receive any benefits since it cant utilize the locked asset in VeAssetDepositor.

1.The owner initially sets _maxTime in constructor to be 126489600 (864003664) instead of 126144000 (864003654) which is the maximum time that a user can deposit in curve

2.A user deposit veAsset but deferring the locking to save gas
3.The veAsset is transferred from a user to the contract and the contract mint a reward token to the user



*Above shows that the deposit will get reverted if lockAmount is more than 4 years in curves VotingEscrow
4.The veAsset will not be able to move to the staking contract because when VoterProxy calls increase_unlock_time in the targeted vault, the call will get reverted due to exceeded _value of unlockAt
The owner should set the value of _maxTime in advance for each veAsset and not relying on manual inputting during the constructoring as the risk of misconfiging ot is high. Otherwise the contract should add an emergency measure that can help change _maxTime but this function needs to be protected with the highest security (eg. with timelock and multisig).
solvetony (veToken Finance) disagreed with severity and commented:
Alex the Entreprenerd (judge) decreased severity to Medium and commented:
