The setRouter
function in both StrategyOp and StrategyArb contracts approves the new router without first revoking approval from the old router address, creating a potential security risk where multiple routers maintain approval to spend the strategy's tokens.
When updating the router address, the contracts grant unlimited approval to the new router without first revoking approval from the previous router.
This can be seen in StrategyArb::setRouter
This means that when the router is updated:
The old router retains its unlimited approval
The new router gets unlimited approval
This accumulates with each router change
Multiple router contracts maintain simultaneous unlimited approval to spend the strategy's underlying tokens
If a previous router becomes compromised, it could still drain funds from the strategy
Each router change increases the attack surface by adding another approved spender
Malicious or compromised previous routers could front-run or manipulate transactions
Manual review
Implement proper approval management by revoking approval from the old router before approving the new one:
This ensures that only the current router has approval at any given time, significantly reducing the security risk surface.
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.