NFTBridge
60,000 USDC
View results
Submission Details
Severity: low
Invalid

Users tokens can get lost if `ownerL2` is set to a contract address which doesn't support ERC721

Github

https://github.com/ArkProjectNFTs/bridge/blob/1bb58731d8e4c37a71d3611c8ea6163c9b019193/apps/blockchain/starknet/src/bridge.cairo#L161

https://github.com/ArkProjectNFTs/bridge/blob/1bb58731d8e4c37a71d3611c8ea6163c9b019193/apps/blockchain/ethereum/src/Bridge.sol#L78-L144

Summary

If ownerL2 is set to a contract address which doesn't support ERC721, the tokens can be permanently lost.

Vulnerability Details

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.

Impact

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.

Recommendation

To mitigate this vulnerability:

  1. 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.

  2. 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.

  3. 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.

Updates

Lead Judging Commences

n0kto Lead Judge 10 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational / Gas

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.

Appeal created

0xtheblackpanther Submitter
10 months ago
0xtheblackpanther Submitter
10 months ago
n0kto Lead Judge
10 months ago
n0kto Lead Judge 9 months ago
Submission Judgement Published
Invalidated
Reason: Non-acceptable severity
Assigned finding tags:

Informational / Gas

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.