Description

The MitosisVault contract has a flaw in the cap-management implementation that could lead to exceeding the intended maximum deposit cap for assets.

In the contract, maxCap represents an asset's maximum cap, while availableCap tracks the remaining capacity that can be deposited. However, the _setCap function incorrectly resets the availableCap to the new cap value without accounting for the already deposited tokens:

function _setCap(StorageV1 storage $, address asset, uint256 newCap) internal {
    AssetInfo storage assetInfo = $.assets[asset];
    uint256 prevCap = assetInfo.maxCap;
    assetInfo.maxCap = newCap;
    assetInfo.availableCap = newCap;
    emit CapSet(_msgSender(), asset, prevCap, newCap);
}

The _deposit function then subtracts the deposited amount from availableCap:

function _deposit(address asset, address to, uint256 amount) internal override(MitosisVaultMatrix, MitosisVaultEOL) {
    // ...
    _assertCapNotExceeded($, asset, amount);

    $.assets[asset].availableCap -= amount;
    IERC20(asset).safeTransferFrom(_msgSender(), address(this), amount);
}

And the deposit validation only checks against the availableCap, not the actual balance in relation to maxCap:

function _assertCapNotExceeded(StorageV1 storage $, address asset, uint256 amount) internal view {
    uint256 available = $.assets[asset].availableCap;
    require(available >= amount, IMitosisVault__ExceededCap(asset, amount, available));
}

This creates a scenario where calling setCap effectively resets the cap tracking, allowing more deposits than intended:

1. Set cap to 100 by calling setCap.

2. Deposit 50 tokens (vault holds 50 tokens, availableCap = 50).

3. Set new cap to 500 by calling setCap — maxCap = 500, and availableCap is reset to 500 (losing track of the 50 already deposited).

4. Deposit 500 more tokens (vault now holds 550 tokens). The vault now contains 550 tokens, exceeding the intended maximum of 500.

The maxCap effectively becomes meaningless since the contract fails to account for the current vault balance when resetting availableCap.

Impact

This issue allows deposits to exceed the intended maximum cap, which could lead to unexpected behavior in dependent systems and potentially violate economic assumptions of the protocol.

Recommendations

Update the _setCap function to properly calculate the availableCap by accounting for the tokens already deposited in the vault.

Remediation

This issue has been acknowledged by Mitosis, and a fix was implemented in commit d0c850d2↗.