The ZlpVault contract is vulnerable to direct transfers of the underlying asset, which can bypass the deposit cap mechanism. This allows malicious actors to grief the system by sending assets directly to the vault, increasing totalAssets() and potentially blocking legitimate deposits once the cap is exceeded.
The maxDeposit function in the ZlpVault contract calculates the maximum allowable deposit by subtracting the current totalAssets() from the deposit cap. However, the totalAssets() value can be increased by direct transfers of the underlying asset to the vault's address, bypassing the deposit function and its associated checks.
The issue arises because totalAssets() includes all assets held by the vault, regardless of whether they were deposited through the deposit function or sent directly via a transfer. This allows an attacker to send assets directly to the vault, increasing totalAssets() and reducing the remaining capacity for legitimate deposits. Once the deposit cap is exceeded, legitimate users will be unable to deposit funds, disrupting the vault's operations.
Malicious actors can send assets directly to the vault, increasing totalAssets() and reducing the available deposit capacity for legitimate users, Once the deposit cap is exceeded, legitimate users will be unable to deposit funds, as maxDeposit will return 0 or underflow revert.
Manual review
To mitigate this issue, the contract should implement a mechanism to track deposits separately from direct transfers.
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.