Missing initializer access control resulting in costly new redeploy and protocol set-up interruption.
In Bridge::initialize
there is not access control and upon contract deployment an attack can call the function and initialize it with arbitrary data which will require a new redeploy of the contract. Even after a new redeploy the attacker may call the function again and again preventing the deployer from being able to initialize the configurations.
Overall, this will may cost additional gas cost due to each new redeployment and interruption of protocol set-up.
Impact: High
Likelihood: Low
Attacker calls Bridge::initialize
before owner which requires costly new redeploy.
Contract Bridge.sol
is deployed.
Attacker immediately calls Bridge::initialize
with arbirary data.
Manual Review
Add onlyOwner access control in Bridge::initialize
:
If frontrun at the first deployment, protocol will deploy again, no real impact: informational. Moreover it is already deployed and initialize on mainnet. For the upgrades, `initialize` can/will change for the next update since the owner is already set. A lot of protocol make that change. That’s why I consider it like a future feature and it is out of scope.
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.