Summary

In the withdrawTokens function of the Starklane bridge contract, the contract checks if the bridge is enabled before allowing users to withdraw their tokens. If the bridge is disabled, the function reverts with a BridgeNotEnabledError. This behavior can inadvertently prevent users from withdrawing their tokens, leaving them unable to reclaim their assets from Layer 2 (L2) even when they should be able to do so.

Vulnerability Details

The withdrawTokens function contains the following check:

This conditional logic ensures that the function will revert if the bridge is disabled. While it makes sense to prevent new deposits or other operations when the bridge is disabled, this logic also prevents users from withdrawing tokens that they have already received from Layer 2 (L2). This creates a scenario where users could be unfairly blocked from accessing their assets, especially during times when the bridge is disabled for maintenance, upgrades, or other reasons unrelated to withdrawals.

Impact

• User Funds Locked: If the bridge is disabled, users may be blocked from withdrawing their tokens, potentially locking their assets on the contract without any means to reclaim them. This could lead to frustration and distrust among users.

• Operational Risk: If the bridge is disabled for an extended period, users' funds may remain inaccessible, posing a risk to the integrity of the system. Users may be unable to move their tokens between L1 and L2, disrupting the utility of the bridge.

Tools Used

Manual Code Review

Recommendations

To avoid blocking users from withdrawing their tokens when the bridge is disabled, the logic should be adjusted to ensure that withdrawals can still be processed regardless of the bridge's enabled/disabled state. This can be achieved by isolating the _enabled check to operations like deposits or other non-withdrawal functions.