Upgradeable contracts use the initialize
function to initialize state variables instead of the constructor in traditional contracts. The TokenManager.sol
contract uses the initialize
function to initialize the TokenManagerStorage::wrappedNativeToken
variable.
The TokenManager::initialize
function has no protection against re-initialization
Thus, the contract can be re-intialized changing the initial values of the state variables. In fact, the contract can be re-initialized so that the wrappedNativeToken
is assigned address(0)
as the TokenManager::initialize
also lacks address zero check.
When TokenManager.sol
is re-initialized using the TokenManager::initialize
function, it results in different TokenManagerStorage::wrappedNativeToken
address for users who interact with the protocol before and after the re-initialization of the contract.
Manual Review
Foundry
Proof of Concept:
Run: forge test --match-test test_TokenManager_Can_ReInitialize
Output:
Thus the address of the wrappedNativeToken
has changed after re-initialization.
Consider protecting the TokenManager::initialize
function against re-initialization by using the initializer
modifier from openzeppelin.
Consider adding the zero address check to the TokenManager::initialize
function
This way, the TokenManager.sol
contract can only be initiallized once and will carry out the zero address check.
The following issues and its duplicates are invalid as admin errors/input validation/malicious intents are1 generally considered invalid based on [codehawks guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). If they deploy/set inputs of the contracts appropriately, there will be no issue. Additionally admins are trusted as noted in READ.ME they can break certain assumption of the code based on their actions, and
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.