Summary

When L2 bridge is disabled, already inflight NFTs (or NFTs that are deposited on L1 after L2 is disabled) would be impacted because they can not be withdrawn on L2. This message can not be retried either, so the NFT would be stuck on L1 permanently.

Vulnerability Details

Suppose an NFT is intended to be bridged from L1 to L2. Different scenarios can happen:

• The NFT is deposited on L1, and while the message is inflight, the bridge on L2 becomes disabled by the admin. Since the withdrawal on L2 is auto, the function withdraw_auto_from_l1 would be called on L2, and it checks whether it is enabled or not. Since, it is disabled while the message was inflight, withdrawal transaction reverts.

https://github.com/Cyfrin/2024-07-ark-project/blob/main/apps/blockchain/starknet/src/bridge.cairo#L134

• L2 bridge is disabled already. But, the L1 bridge is not disabled yet since L1 and L2 are asynchronous. So, depositing the NFT on L1 would be possible, but withdrawing on L2 would not be possible due to ensure_is_enabled(@self); in the function withdraw_auto_from_l1.

When any of these scenarios happen, starknet considers the message as accepted on L2 but the result is reverted. So, cancelling such messages from L1 would not be possible, because during processing the L1 to L2 messages, starknet sets messages[messageHash] = 0, i.e. the message is delivered on L2 (whether it is reverted or successful does not matter).

https://github.com/starkware-libs/cairo-lang/blob/v0.13.2a0/src/starkware/starknet/solidity/Output.sol#L151

Moreover, retrying a reverted message on starknet is not possible as the withdrawal is auto.

As a result, the NFT would be stuck on L1, while associated L2 collection is not released to the receiver.

Impact

• Stuck/loss of NFT on L1.

Tools Used

Recommendations

It is recommended that in such scenarios during withdrawal on L2, the message be stored in a mapping, and later when the L2 bridge is enabled again, it can be withdrawn manually.