Part 2

Summary

The ZlpVault contract's deposit cap mechanism can be bypassed through direct token transfers. The maxDeposit function relies on ERC4626's totalAssets()—which includes tokens sent directly to the vault—to enforce the deposit cap. This flaw allows an attacker to artificially inflate the vault's asset balance outside of the authorized deposit function, thereby blocking legitimate deposits.

Vulnerability Details

Location: ZlpVault.sol (approximately lines 89-108)

The core issue lies in the implementation of the maxDeposit function:

Since totalAssets() aggregates all tokens held by the vault, including those sent via plain transfers, an attacker can bypass proper deposit accounting by directly sending tokens to the vault. As demonstrated in our tests, this manipulation can completely block legitimate deposit attempts.

Impact

• Deposit Blockage: An attacker can prevent further deposits by artificially inflating the vault's recorded asset balance.

• Disruption: Legitimate users may have their deposits reverted, potentially forcing them to pay higher gas fees or wait until the malicious tokens are removed.

• Protocol Integrity: The incorrect assumption in deposit cap enforcement could affect other protocol components relying on accurate asset tracking.

Proof of Concept

1. Initial Deposit & Direct Transfer Attack:

   • The deposit cap is set at 1000 USDC.

   • A legitimate deposit of 800 USDC yields maxDeposit of 200 USDC.

   • An attacker then directly transfers 200 USDC, which makes totalAssets() equal to 1000 USDC.

   • As a result, maxDeposit returns 0, and subsequent deposit attempts revert (e.g., with a SlippageCheckFailed error).

2. Repeated Small Direct Transfers:

   • Multiple small transfers can cumulatively deplete the available deposit capacity.

3. Precision Testing with Small Amounts:

   • Even very small transfers accurately reduce the available max deposit, highlighting the precision of this bypass.

These tests conclusively prove that direct token transfers can be used to bypass the intended deposit cap logic.

Recommendations

1. Separate Deposit Accounting:

   • Track payments made through the authorized deposit function separately (e.g., using a totalDeposited variable) and base maxDeposit calculations on this value instead of totalAssets().

   Example Fix:

   contract ZlpVault {

   uint256 public totalDeposited;

   function maxDeposit(address) public view override returns (uint256 maxAssets) {

   uint128 depositCap = marketMakingEngine.getDepositCap(zlpVaultStorage.vaultId);

   return depositCap > totalDeposited ? depositCap - totalDeposited : 0;

   }

   function deposit(uint256 assets, address receiver) public override onlyMarketMakingEngine returns (uint256) {

   totalDeposited += assets;

   return super.deposit(assets, receiver);

   }

   }

2. Reject Direct Transfers:

   • Consider overriding ERC4626's asset handling functions to reject direct transfers that bypass proper deposit logic.

3. Enhanced Monitoring and Auditing:

   • Implement monitoring to detect abnormal increases in totalAssets() and ensure vault operations reflect only legitimate deposits.