Summary

The StrategyOp.sol and StrategyArb.sol contracts allow for update of the router address via the setRouter(...)function as seen here: https://github.com/Cyfrin/2024-12-alchemix/blob/82798f4891e41959eef866bd1d4cb44fc1e26439/src/StrategyArb.sol#L42-L45
and here https://github.com/Cyfrin/2024-12-alchemix/blob/82798f4891e41959eef866bd1d4cb44fc1e26439/src/StrategyOp.sol#L48-L51
as

The contract during initialization approves type(uint256).max underlying tokens to the router address as seen here: https://github.com/Cyfrin/2024-12-alchemix/blob/82798f4891e41959eef866bd1d4cb44fc1e26439/src/StrategyOp.sol#L39
and https://github.com/Cyfrin/2024-12-alchemix/blob/82798f4891e41959eef866bd1d4cb44fc1e26439/src/StrategyArb.sol#L37

The setRouter(...) function allows for updating the router address and approves type(uint256).maxof underlying tokens to the newly set router address but does not revoke approvals to the old router address.

Vulnerability Details

Whenever, a router address is updated, it is approved type(uint256).maxof underlying tokens via the setRouter(...)function. However, there is no mechanism in the entire contract to revoke approvals to the old router address. As a result, in the event there is a bug or security issue with the old router address, hence the update, all the strategy's underlying tokens are at risk.

Impact

All underlying tokens of StrategyArb.sol and StrategyOp.sol are at risk of spenditure from the old router address in the event there is an update to a new router address as a result of a security risk or bug from the old router address. The project should consider implementing a mechanism to disable approvals to old router address after updating a router address.

Tools Used

Recommendations

Consider implementing a mechanism to revoke old router approvals when updating a router address