Summary

A vulnerability has been identified in the method getProxyAddress where an address generation mechanism doesn't check if the derived address is already in use.

Vulnerability Details

The function getProxyAddress generates an Ethereum address based on the provided salt and implementation. This is done using the create2 opcode, which allows for deterministic address generation. While this can be a powerful feature, it also presents risks if not used carefully.

The issue arises due to the absence of a check to ensure the generated address isn't already occupied by a contract. If someone, knowingly or unknowingly, deploys a contract to an address that would in the future be produced by this function, any sponsors who send tokens to the supposed "new" proxy contract address would be sending tokens to the wrong place.

POC:
Manual Address Calculation: A malicious actor or an innocent third party calculates an address using the same methodology as the getProxyAddress function.

Preemptive Deployment: The actor deploys a contract or simply sends tokens to the calculated address.

Legitimate User Interaction: A legitimate user uses the getProxyAddress function later on with the same salt and implementation combination. They are provided with the previously calculated address.

Token Transfer: Assuming the address from getProxyAddress is a fresh proxy, sponsors might send tokens to it. Those tokens would then end up in the wrong place, potentially leading to loss of funds or assets being locked without recovery options.

Impact

Any tokens or funds sent to the generated proxy address, assuming it's a fresh contract, could potentially be lost or end up in an unexpected contract.

Tools Used

Manuel reviews

Recommendations

Implement a check in the getProxyAddress function to verify if the generated Ethereum address is already occupied. It is advised not to send funds before deployment as they could be lost