The depositQueuedTokens function in the PriorityPool contract lacks proper access control, allowing any external actor to call it. This vulnerability could potentially lead to manipulation of the contract's state, bypassing of deposit limits, and disruption of the normal deposit flow.
The depositQueuedTokens function is defined as follows:
This function is external and lacks any access control modifiers. It calls the internal _depositQueuedTokens function, which can modify important contract state variables such as totalQueued and depositsSinceLastUpdate. The function also allows bypassing of the stored deposit limits like mentioned in the documentation:
Which could be exploited if called by unauthorized parties.
While the function does have some internal checks (e.g., ensuring the pool is open and there's sufficient deposit room), these are not sufficient to prevent potential misuse by malicious actors.
The lack of access control on this function could lead to several potential issues:
Timing attacks: An attacker could call this function at inopportune moments, disrupting the normal flow of deposits.
State manipulation: The contract's state could be manipulated by calling this function with carefully chosen parameters.
Bypassing limits: The ability to bypass deposit limits could be exploited, potentially leading to unexpected behavior in the contract.
These issues could result in financial losses, disruption of the protocol's intended functionality, or manipulation of the system to an attacker's advantage.
Manual review
Restrict the function to only be callable by the contract owner or add a new role with only authorised accounts being able to call the function using a relevant modifier.
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.