Summary

The L2TokenReceiver utilizes the router address as an argument during the initialization (init) process. The concern arises from the fact that the init function is typically executed once during deployment. This design choice limits the ability to update the router address dynamically after deployment, potentially hindering adaptability to future changes.

Vulnerability Details

The contract's initialization function (init) accepts the router address as an argument, allowing flexibility during the deployment phase. However, once the contract is deployed and initialized, there is no mechanism provided to update the router address. As a result, changes to the Uniswap V3 router contract address would necessitate a redeployment of the entire contract.

Impact

The absence of a dedicated function to update the router address post-deployment poses challenges in scenarios where the Uniswap V3 router contract needs replacement or updates. Despite the contract inheriting from OwnableUpgradeable, implying ownership control, the lack of a specific upgradability mechanism makes future upgrades challenging. This limitation could result in downtime and introduce additional operational complexities when adapting to changes in the Uniswap V3 router contract.

Recommendations

Consider implementing a function that allows the owner of the contract to update the router address after deployment. This update mechanism should be designed with appropriate access controls, such as the onlyOwner modifier, to ensure that only authorized entities can modify the address.

For example, adding a function like this will be good option: