The strategy contracts (StrategyOp.sol, StrategyArb.sol, and StrategyMainnet.sol) implement a setRouter
function that grants infinite token approvals to new routers without revoking approvals from previously approved routers. This could lead to security vulnerabilities if a previously approved router becomes compromised.
When the management role calls setRouter
to update the router address, the function grants an unlimited approval (type(uint256).max) to the new router without first revoking approvals from the old router address.
The vulnerability exists in:
StrategyOp.sol
StrategyArb.sol
StrategyMainnet.sol
Severity: High
If a previously approved router contract becomes compromised (through upgrades, vulnerabilities, or malicious actions), the attacker could:
Drain all underlying tokens up to the infinite approval amount
Front-run or manipulate swaps
Execute unauthorized token transfers
Exploit the approval across multiple transactions
The impact is heightened because:
Approvals are for the maximum possible amount (type(uint256).max)
Multiple routers can have simultaneous infinite approvals
Attack could be executed at any time after router change
Recovery requires management intervention
Manual code review
Implement proper approval revocation in the setRouter function:
Consider using incremental approvals instead of infinite approvals
Add events for approval changes
Implement a maximum approval amount configuration
Add emergency approval revocation functionality
Added test cases should include:
Pending implementation
Management role access
Multiple router changes
Underlying token balance
Deploy strategy with Router A
Change router to Router B using setRouter
Verify Router A still has infinite approval
Using Router A account, attempt token transfer
Observe successful unauthorized transfer
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.