Vulnerability Details

When Deploying a new ERC721 collection on L1, we are creating a new instance of ERC721Bridgeable(), and deploy it as a Proxy to be able to upgrade it.

Deployer.sol#L30

Since this interface ERC721Bridgeable is a constant bytecode when compiling the contract, it will make the code logic of ERC721 that will get deployed when withdrawing from L1 immutable and we can't change its logic.

If we checked L2Bridge we will find this is not how it works, where it supports changing the logic of the ERC721 collection that will get deployed on L2. There is a function called set_erc721_class_hash() which changes the class_hash of the ERC721 collection addresses (which is like changing the bytecode in EVM/solidity).

bridge.cairo#L220-L223

And by changing erc721_bridgeable_class the newly created NFTs collections on L2 will have the Logic that represents that class_hash.

bridge.cairo#L448-L455

So in L2Bridge we will be able to change the Code Logic of the ERC721 collection that will get deployed, but in L1Bridge we will not be able to do this. which means that the two Bridges are not consistent.

Tools Used

Manual Review

Recommendations

1. Make the bytecode a variable that can be changed, and since there is no constructor argument this will be enough.

2. Make the creation using create opcode, with providing that bytecode variable.