Core Contracts

Summary

The staking mechanism allows arbitrary token deposits without restricting the maximum deposit amount. This can result in incorrect accounting issues when staking tokens like cUSDCv3, which have custom logic for transferFrom.

Vulnerability Details

• The function stake(uint256 amount) in BaseGauge.sol does not validate the amount.

• Some tokens like cUSDCv3 treat type(uint256).max as "transfer entire balance."

• If a user stakes type(uint256).max, the protocol may incorrectly register the amount as the maximum uint256 value, while only transferring the user's balance.

• This results in accounting mismatches and may allow stake inflation attacks.

PoC

Staking allows type(uint256).max deposits, leading to incorrect reward accounting.

Exploit Scenario

• The attacker stakes type(uint256).max tokens.

• The protocol incorrectly registers an inflated stake amount.

• The attacker drains more rewards than they actually deposited.

PoC Exploit

Expected Outcome

• The attacker receives excessive staking rewards.

• Protocol reward distribution is broken.

• Possible fund loss due to incorrect accounting.

Impact

• Protocol fund loss: If the incorrect stake amount is later withdrawn, it may exceed actual deposits.

• Incorrect reward calculations: Users may receive more staking rewards than intended.

• Potential exploit: Malicious users can use inflated stake amounts to drain staking rewards.

Tools Used

• Manual Review of BaseGauge.sol

• Echidna Fuzzing for incorrect stake scenarios

Recommendations

• Implement a check to prevent type(uint256).max from being passed as a staking amount.

• Use require(amount < MAX_STAKE_LIMIT, "Stake amount too high"); to limit deposits.

• Conduct unit tests with edge cases involving tokens like cUSDCv3.