The setRouter
function does not revoke the approval for the previous router address before granting approval to the new router. This oversight may leave the contract vulnerable to exploits by increasing the number of unnecessary approvals.
In the setRouter
function, the contract updates the router
address and grants approval for the new router. However, it does not revoke the approval for the old router before this update. This could result in the old router address still having token approvals, which could potentially lead to unauthorized transactions or waste resources if exploited by a malicious actor.
In the absence of revoking approvals for the old router address, malicious or unintended interactions with the previous router could still occur, making the system more prone to manipulation or errors.
Increased attack surface: An attacker who gains control over the old router address could misuse the approvals to manipulate funds.
Potential funds loss: Funds that are approved but not properly revoked might be manipulated by an attacker, leading to unintended transactions or exploitation.
Operational inefficiency: Having unused or redundant approvals increases the risk of interacting with unintended contracts, causing unnecessary failures and wasted resources.
Manual Code Review
Modify the setRouter
function to revoke approval for the old router address by calling underlying.safeApprove(oldRouter, 0)
before approving the new router. This ensures that only the current router has token approvals and reduces the risk of attacks from unrevoked approvals.
A robust solution involves ensuring that token approvals are always correctly managed and revoked before being reassigned, thereby securing the contract from unauthorized interactions.
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.