# Deposits/Withdrawals/Orders will be canceled if created before feature is disabled and attempted to be executed after

GMX keepers executing deposits/withdrawals/orders while the feature is disabled trigger cancellation, charging users the execution fee for a failed operation.

- Payout: Contest reward
- Severity: medium
- Program: Gmx
- Credited: 0xdeadbeef
- Disclosed: 2022-09-22
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/124
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AM-30
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** DepositHandler/WithdrawHandler/OrderHandler execution and cancellation path
**Root cause:** The feature-disabled check reverts during execution, but the catch block calls cancelDeposit/cancelWithdrawal/cancelOrder which lack the feature-disabled validation, so cancellation succeeds and charges the user's execution fee.
**Steps:**
1. Bob calls `createDeposit` with an execution fee.
2. Admin disables deposits (maintenance).
3. Keeper calls `executeDeposit`; the feature-disabled check at DepositHandler.sol#L144-L150 reverts.
4. Catch block calls `_handleDepositError` -> `DepositUtils.cancelDeposit`, which has no feature check.
5. Deposit is cancelled and the execution fee is paid to the keeper from Bob's funds.
**How found:** Code reading of the execution handler: noticed the feature-disabled revert is caught by the generic catch, then traced into the cancel function and observed it lacks the same feature validation present in the create/execute paths.
**Exploitation:** A keeper (or anyone triggering execution) executes a pending deposit/withdrawal/order while the feature is disabled; the revert is caught and the cancellation path runs without the feature guard, deducting the execution fee from the user.
**Insight:** When a protocol gates operations behind a feature flag, check every code path that can be reached from the failure/catch branch (cancel, refund, cleanup) — guards on create/execute often miss the error-handling path that still moves user funds.