You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 7, 2024. It is now read-only.
sherlock-admin opened this issue
Jul 8, 2023
· 0 comments
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
In the current contract setup, when an order is completed, users' claimable balance increases and waits idle until claimed by the users. They can pay the claim fee using either ETH or WETH. However, the contract design allows the owner to withdraw the entire WETH balance using the withdrawNative() function. This feature can be exploited to steal any unclaimed WETH balance of users, causing errors in accounting and rendering the contract unusable.
Vulnerability Detail
When an order is fulfilled by keepers or anyone, the claimable balance of the users of the particular order is increased and stands idle until users claims it. When a user claims the claimable balance user either pays the claim fee with ETH or WETH. Those WETH that's been collected in the contract can be swept by the owner by calling the withdrawNative(). However, withdrawNative function claims the entire WETH balance of the contract. If any user has a claimable WETH balance waiting in the contract owner can call withdrawNative() to steal them. Furthermore, this will make the user to not be able to claim its claimable balance and all the accounting will go wrong inside the contract.
Impact
Not only owner can steal the user funds, this would also make the contract inoperable. Since the users claimable amount is not available in the contract, as soon as some other range order goes through the same user can now claim making the newly fulfilled order users wait. In addition to that, any fees that's collected in terms of WETH will also be accounting completely wrong since the balances already withdrawn.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
DuplicateA valid issue that is a duplicate of an issue with `Has Duplicates` labelHighA valid High severity issueRewardA payout will be made for this issue
mstpr-brainbot
high
Owner can take the users claimable WETH balances
Summary
In the current contract setup, when an order is completed, users' claimable balance increases and waits idle until claimed by the users. They can pay the claim fee using either ETH or WETH. However, the contract design allows the owner to withdraw the entire WETH balance using the withdrawNative() function. This feature can be exploited to steal any unclaimed WETH balance of users, causing errors in accounting and rendering the contract unusable.
Vulnerability Detail
When an order is fulfilled by keepers or anyone, the claimable balance of the users of the particular order is increased and stands idle until users claims it. When a user claims the claimable balance user either pays the claim fee with ETH or WETH. Those WETH that's been collected in the contract can be swept by the owner by calling the withdrawNative(). However, withdrawNative function claims the entire WETH balance of the contract. If any user has a claimable WETH balance waiting in the contract owner can call withdrawNative() to steal them. Furthermore, this will make the user to not be able to claim its claimable balance and all the accounting will go wrong inside the contract.
Impact
Not only owner can steal the user funds, this would also make the contract inoperable. Since the users claimable amount is not available in the contract, as soon as some other range order goes through the same user can now claim making the newly fulfilled order users wait. In addition to that, any fees that's collected in terms of WETH will also be accounting completely wrong since the balances already withdrawn.
Code Snippet
https://github.com/sherlock-audit/2023-06-gfx/blob/main/uniswap-v3-limit-orders/src/LimitOrderRegistry.sol#L505-L515
Tool used
Manual Review
Recommendation
Duplicate of #48
The text was updated successfully, but these errors were encountered: