Description

The core MetaMorphoV1_1 vault operations — deposit, mint, withdraw, and redeem — all invoke _accrueInterest() before executing their main logic. Additionally, administrative functions setFee() and setFeeRecipient() also call _accrueInterest() to ensure fees are properly accrued before parameter changes.

Within _accrueInterest(), when feeShares is nonzero, the function calls FEE_PARTITIONER.getShares() to determine the fee split between the platform and the vault's fee recipient:

function _accrueInterest() internal {
    // [...]
    if (feeShares != 0) {
        (uint256 platformShare, uint256 recipientShare) = FEE_PARTITIONER.getShares(address(this), feeShares);
        // [...]
    }
    // [...]
}

The FEE_PARTITIONER address is immutable and set during contract deployment, creating a permanent dependency:

IMetaFeePartitioner internal immutable FEE_PARTITIONER;

Because MetaFeePartitioner is an upgradable contract (inheriting from UUPSUpgradeable), there is a centralization risk. If the MetaFeePartitioner owner's private key is compromised, an attacker could upgrade the contract to a malicious implementation where getShares() reverts. This would cause _accrueInterest() to revert whenever feeShares != 0, thereby blocking MetaMorphoV1_1 vault operations that require fee accrual.

Impact

If a wallet controlling MetaFeePartitioner ownership were compromised, an attacker could halt all MetaMorphoV1_1 vaults with nonzero accrued feeShares by upgrading MetaFeePartitioner to an implementation that reverts in getShares.

Recommendations

We recommend holding MetaFeePartitioner ownership in a timelocked multi-sig, enforcing upgrade delays, and monitoring upgrade proposals to detect and respond to malicious implementations before they take effect to reduce centralization risk.

Remediation