If ownerL2
is set to a contract address which doesn't support ERC721, the tokens can be permanently lost.
The transfer_from
function in the Cairo ERC721 implementation contains a warning stating: "This method may lead to the loss of tokens if to
is not aware of the ERC721 protocol" (see OpenZeppelin ERC721 Cairo implementation and this). When bridging tokens back from L1 to L2, if ownerL2
is set to a contract address that does not support ERC721 tokens, the withdraw_auto_from_l1
function will attempt to transfer tokens to this contract address using the transfer_from
function.
Since the recipient contract does not support ERC721 tokens, it will not be able to handle or manage these tokens properly. As a result, there will be no mechanism to retrieve or manage the tokens from the contract, effectively leading to their loss. This issue arises because the ERC721 protocol requires certain functions and handling mechanisms that the non-supporting contract will lack.
Users' tokens can be lost if sent to a contract address that does not support ERC721. The tokens will be locked in the recipient contract, and users will not be aware of this issue until it is too late, resulting in potential significant financial losses.
To mitigate this vulnerability:
Implement Address Validation: Before transferring tokens, validate that the ownerL2
address supports the ERC721 protocol. This can be done by checking if the contract implements the ERC721 interface.
User Warnings and Documentation: Inform users through documentation and warnings about the risks of setting ownerL2
to a contract address that does not support ERC721 tokens.
Safe Transfer Mechanism: Implement a safe transfer mechanism that reverts the transaction if the recipient contract does not support ERC721, ensuring that tokens are not lost.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.