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.