"Wardens should assume that governance variables are set sensibly (unless they can find a way to change the value of a governance variable, and not counting social engineering approaches for this)."
Even with the statement above in mind I still find it relevant to report that without a timelock a malicious address could be whitelisted without any barriers.
If a current whitelisted address turned got comprimised or became ill intended there is nothing stopping it fom abusing its power and whitelisting an address containing harmful functionality.
function manageWhitelist(
address[] memory _users,
bool _isWhitelisted
) public onlyWhitelisted {
for (uint256 i = 0; i < _users.length; i++) {
require(
_users[i] != address(0),
"User is the zero address"
);
whitelisted[_users[i]] = _isWhitelisted;
}
emit WhitelistedStatusModified(msg.sender, _users, _isWhitelisted);
}
No time lock on whitelisting.
Recommended Mitigation Steps
Implement time lock so suspicious whitelisting activity could be examined and prevented.
Lines of code
Gravity.sol#L124
Vulnerability details
Impact
"Wardens should assume that governance variables are set sensibly (unless they can find a way to change the value of a governance variable, and not counting social engineering approaches for this)."
Even with the statement above in mind I still find it relevant to report that without a timelock a malicious address could be whitelisted without any barriers.
If a current whitelisted address turned got comprimised or became ill intended there is nothing stopping it fom abusing its power and whitelisting an address containing harmful functionality.
Proof of Concept
Gravity.sol#L124-L136
No time lock on whitelisting.
Recommended Mitigation Steps
Implement time lock so suspicious whitelisting activity could be examined and prevented.