The strategy
contract allows management
to change the router via the setRouter
function. While the new router receives maximum approval for WETH
, the approval for the previous router is not revoked. This oversight can result in security risks, particularly if the previous router becomes malicious or compromised.
The router
acts as a DEX
through which the keeper
swaps WETH
for ALETH
in case of depegging:
Hence, the router
requires maximum approval to execute these swaps. The functions _initStrategy
and setRouter
are responsible for granting this approval:
Also, the strategy
is likely to have underlyingBalance
in the contract.
However, the approval for the previous router is not revoked when setRouter
is called. As a result, the previous router retains unlimited access to the contract’s WETH
balance, even though it is no longer intended for use. This could have severe consequences if:
The previous router becomes malicious.
The previous router is compromised in an exploit or contract upgrade vulnerability, as seen in incidents like the LQDX hack (reference).
Retaining maximum approval for the previous router exposes the contract’s WETH
to theft or abuse, which could result in significant financial losses. This risk is exacerbated by the likelihood of a router being compromised or maliciously upgraded.
Manual
To mitigate the issue, before assigning maximum approval to the new router, revoke the approval for the old router to prevent unauthorized access.
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.