0x00ffDa - Liquidation frontrunning can prevent debt repayment upon unpausing (restoring full router)

[sherlock-admin]

0x00ffDa

high

Liquidation frontrunning can prevent debt repayment upon unpausing (restoring full router)

Summary

During a period of time that the PauseRouter is in use, the valuations of a user's debt and collateral may make them subject to liquidation. But, in the first block after the normal Router is restored, MEV bots can preempt any transactions that could prevent the liquidation (e.g. repayment or adding collateral).

Vulnerability Detail

Pausing and unpausing the router is performed via a call to the active router's inherited UUPSUpgradeable.upgradeTo() (or upgradeToAndCall()) function and supplying the address of the next router contract, which calls GovernanceAction._authorizeUpgrade() and then ERC1967Upgrade._upgradeToAndCallSecure() which ends with ERC1967Upgrade._upgradeTo() switching the implementation address to realize the desired change. Pausing may be performed by either the owner or the pause guardian role. Only the owner can unpause the system.

Notional has forked governance logic from Compound. In Compound, "Importantly, the pauseGuardian does not have the ability to prevent users from exiting their positions by calling redeem or repayBorrow". However, in Notional this is not true. The PauseRouter does not delegate account action functions that would allow debt repayment. As such, without recourse to avoid it, user debt positions may become liquidatable during a pause.

MEV bots are able to use view functions to monitor account health during a pause. So, while they may actively detect and frontrun debt repayment transactions upon system unpausing, it is not required. The normal operation of liquidators bots can have the same effect.

Note that liquidations may be enabled during a pause as well. (That is determined by system configuration at the discretion of the owner or pause guardian and enabling it would pose additional liquidation risk to users.) The frontrunning vulnerability is present even if liquidations are not enabled during a pause.

Ref: audit finding

Impact

By frontrunning any debt repayment (or collateral deposit) attempts after unpausing the router, MEV bots can unfairly liquidate all debt positions that became eligible for liquidation during the pause. This causes loss of funds to all affected users.

Code Snippet

Tool used

Manual Review

Recommendation

If liquidation is not allowed during a pause, add a grace period after unpausing during which liquidation remains blocked to allow users to avoid unfair liquidation by repaying debt or supplying additional collateral.

[0x00ffDa]

Escalate for 10 USDC

I believe this finding should be reclassified as "High" severity because it meets all the current Sherlock criteria for "High" issues:

High: This vulnerability would result in a material loss of funds, and the cost of the attack is low (relative to the amount of funds lost). The attack path is possible with reasonable assumptions that mimic on-chain conditions. The vulnerability must be something that is not considered an acceptable risk by a reasonable protocol team.

Specifically ... unfair liquidation is a material loss of user funds and can occur with low cost by any liquidator. Use of the PauseRouter is expected in any upgrade and it may also be used in other circumstances, so this is not "stars must align" scenario. The sponsor has already confirmed this is a valid finding.

[sherlock-admin]

Escalate for 10 USDC

I believe this finding should be reclassified as "High" severity because it meets all the current Sherlock criteria for "High" issues:

High: This vulnerability would result in a material loss of funds, and the cost of the attack is low (relative to the amount of funds lost). The attack path is possible with reasonable assumptions that mimic on-chain conditions. The vulnerability must be something that is not considered an acceptable risk by a reasonable protocol team.

Specifically ... unfair liquidation is a material loss of user funds and can occur with low cost by any liquidator. Use of the PauseRouter is expected in any upgrade and it may also be used in other circumstances, so this is not "stars must align" scenario. The sponsor has already confirmed this is a valid finding.

You've created a valid escalation for 10 USDC!

To remove the escalation from consideration: Delete your comment.

You may delete or edit your escalation comment anytime before the 48-hour escalation window closes. After that, the escalation becomes final.

[0xleastwood]

Escalate for 10 USDC

I believe this finding should be reclassified as "High" severity because it meets all the current Sherlock criteria for "High" issues:

High: This vulnerability would result in a material loss of funds, and the cost of the attack is low (relative to the amount of funds lost). The attack path is possible with reasonable assumptions that mimic on-chain conditions. The vulnerability must be something that is not considered an acceptable risk by a reasonable protocol team.

Specifically ... unfair liquidation is a material loss of user funds and can occur with low cost by any liquidator. Use of the PauseRouter is expected in any upgrade and it may also be used in other circumstances, so this is not "stars must align" scenario. The sponsor has already confirmed this is a valid finding.

The pause router is not expected in any upgrade to the Notional protocol. It is only used in an emergency situation, so by definition, this is already an unlikely scenario to occur. Additionally, it would be safer to allow for liquidations after the protocol has been unpaused because this is how the protocol is designed to stay solvent. Adding an arbitrary grace period only adds to the risk that a vault position may become undercollateralised. If anything, a better approach would be to allow for vault accounts to be liquidated from within the pause router because this functionality isn't currently enabled.

[0xleastwood]

I do think Notional prioritises protocol solvency in this emergency situations over user experience and I think this is the correct approach.

[0x00ffDa]

The pause router is not expected in any upgrade to the Notional protocol.

From my reading of the V3 upgrade script, it does plan to use the PauseRouter.

[0xleastwood]

The pause router is not expected in any upgrade to the Notional protocol.

From my reading of the V3 upgrade script, it does plan to use the PauseRouter.

I think this is unique to V3 migration because it takes a bit of time and requires multiple steps to perform. But generally speaking, most patch fixes can be done atomically.

[jeffywu]

The vulnerability must be something that is not considered an acceptable risk by a reasonable protocol team.

We will take this risk during the upgrade. So if that is the definition of a high priority issue then this is not a high priority issue.

[hrishibhat]

Result:
Medium
Unique
Considering this issue a valid medium given the circumstances under which this would occur and as mentioned by the Sponsor this can be considered an accepted risk.

[sherlock-admin]

Escalations have been resolved successfully!

Escalation status:

• 0x00ffDa: rejected