The vulnerability is related to a potential re-organization (re-org) attack in a smart contract function responsible for deploying
an ERC721 token. The function deployERC721Bridgeable creates a new instance of an ERC721 token and deploys it using the ERC1967Proxy pattern.
However, the deployment process is susceptible to a re-org, which can have serious security implications.
In the provided deployERC721Bridgeable function, a new instance of an ERC721Bridgeable token is deployed, and its initialization data
is encoded and passed to ERC1967Proxy. The function is designed to return the address of the newly deployed proxy contract.
A blockchain re-organization (re-org) can occur when two or more competing blocks are produced simultaneously, leading to one chain
being discarded in favor of another. If a re-org happens after this function is executed, but before the transaction is confirmed
in the final block, the deployment process can be disrupted.
If a re-org occurs, the contract deployment could be rolled back, leading to a situation where the deployERC721Bridgeable function returns
an address that no longer points to a valid contract. This could cause downstream contracts or users to interact with an address
that doesn’t contain the expected contract logic, leading to potential loss of funds, broken functionality, or other security vulnerabilities.
Poc:
The impact of this vulnerability can be severe, especially in a system where the correctness of contract addresses is critical.
If a re-org results in an invalid or non-existent contract address being returned:
`_l1ToL2Addresses` and `_l2ToL1Addresses` can only be set by the bridge owner or at the deployment in `withdrawTokens`. Even if there is a reorg, the contract will be deployed on a new address which won’t change anything to bridge tokens. No impact.
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.