Part 2

Summary

VaultRouterBranch:: compares the delta (difference) between the vault’s credit capacity before and after the redeem to a locked credit threshold, rather than ensuring the vault’s final credit capacity remains above that threshold. As a result, users may be able to redeem assets even if it causes the vault’s remaining credit capacity to fall below the required locked level, potentially destabilizing the protocol’s financial guarantees.

Vulnerability Details

The following check is made in VaultRouterBranch::redeem :

the code is comparing the difference in credit capacity (beforeRedeem - afterRedeem) to the locked capacity threshold (ctx.lockedCreditCapacityBeforeRedeemUsdX18) to attempt to make sure that if the credit capacity delta is greater than the locked credit capacity before the state transition the function reverts . In the code block, this isnt what happens as it ends up checking if the credit capacity delta is less than or equal to the locked credit capacity before the state transition.

This is one of a two fold issue. The second issue is with the underlying logic because the intended goal is to ensure that after redeeming, the vault’s remaining credit capacity stays above the locked threshold.
The intended design intends the vault always to maintain at least a certain amount of credit capacity (i.e., lockedCreditCapacity), as per the natspec which defines Vault::lockedcreditratio as:

Due to the flawed comparison, a malicious or opportunistic user might be able to redeem an amount that causes the vault’s final credit capacity to drop below its required locked threshold without triggering an error or reverting.

Locked credit capacity is calculated in Vault::getLockedCreditCapacityUsd. See below:

The total credit capacity is calculated by multiplying the total credit capacity by the lockedcreditratio set by the protocol when configuring the vault via Vault::update.

Proof Of Code (POC)

Impact

Systemic Risk: Once the vault’s post-redeem credit capacity falls below the locked threshold, the protocol may be unable to honor future credit obligations or maintain sufficient reserves, putting the entire system at risk.
Financial Losses: If the vault cannot cover its obligations, users or other stakeholders could suffer substantial losses.
Exploitation Potential: Attackers may repeatedly exploit this bug to drain vault capacity, leading to destabilization and potential insolvency for the protocol.

Tools Used

Manual Review, Foundry

Recommendations

Compare Final Capacity to Locked Threshold:
Replace the capacity-delta check with a direct comparison between the vault’s new (post-redeem) total credit capacity and the locked threshold. For example: