Lack of logic in function _verifyRequestAddresses
in CollectionManager.sol
causes tokens that has no mapping cannot be withdrawed unless the mapping is updated by the owner.
Users withdraw their token usnig the withdrawTokens
function in Bridge.sol
. Some checks and verification are performed, 1 of them is the _verifyRequestAddresses
in CollectionManager.sol
. Basically this function checks whether the _l1ToL2Addresses
mapping contains the L1 collection address and L2 collection address requested by the user as seen on the code below.
If the _l1ToL2Addresses
mapping do not contains the requested L1 collection address then the user cannot withdraw the requested tokens. Looking at the function it only account for scenarios where:
L2 collection address is present L1 collection address is present
L2 collection address is present L1 collection address is not
But not when L1 collection address is present and L2 collection address is not.
This should not be a problem if users cannot deposit their token in the first place if the mapping does not contains the requested L1 collection address. But the depositTokens
function in Bridge.sol
actually allows any ERC721 token to be deposited even if the mapping do not contain the L1 collection address yet if the owner has not enabled whitelisting through enableWhitelist
function.
Uncomment line 88 to simulate the owner set the mapping for the L1 collection
Users are unable to withdraw their tokens until the mapping is updated by the owner, which poses a significant problem if users wish to change their minds and transfer their tokens elsewhere. While the owner can resolve the issue by updating the mapping, there is no assurance regarding the timeframe for this update. Given the vast number of L1 collection addresses out there, it is impractical for the owner to update the mapping for every address out there. Additionally, this could lead to reputational damage if a user affected by this issue accuses the protocol or project of theft and the accusation gains traction on social media.
Manual review
Foundry
Do not allow deposit of token that has no mapping so that users does not accidentally lock their tokens in the escrow using require
statement somewhere in the depositTokens
function in Bridge.sol
, something like this:
Likelyhood: High, any collections bridged, without bridge owner action, will be unable to bridge back. Impact: High, L2 -> L1 tokens will be stuck in the bridge. L1 -> L2 will need to ask for a cancellation.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.