# Stop-loss orders do not become marketable orders

GMX stop-loss orders revert when primary/secondary oracle prices no longer straddle the trigger price, leaving positions without stop-loss protection after fast price moves.

- Payout: Contest reward
- Severity: medium
- Program: Gmx
- Credited: Ch_301
- Disclosed: 2023-04-20
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-04-gmx-judging/issues/233
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-04-gmx%3AM-7
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** GMX Synthetics stop-loss order validation (BaseOrderUtils.ok / OrderHandler)
**Root cause:** Stop-loss validation requires primaryPrice and secondaryPrice to straddle the trigger price; if both moved past the trigger (fast move or oracle outage), the check fails and the order reverts instead of executing as a market order.
**Steps:**
1. Submit a StopLossDecrease order with trigger price $99 while price is $100.
2. Before the keeper executes, price drops so primary/secondary are $97/$96.
3. Keeper calls execute; BaseOrderUtils.ok computes ok = (primaryPrice >= triggerPrice && triggerPrice >= secondaryPrice) which is false.
4. Errors.InvalidStopLossOrderPrices is raised and OrderHandler._handleOrderError re-reverts, wedging the order.
**How found:** Code review of stop-loss price validation in BaseOrderUtils.ok and the error-handling path in OrderHandler._handleOrderError, comparing against standard financial stop-loss semantics where the order becomes a market order once triggered.
**Exploitation:** Not an attack; a keeper attempting execution reverts, so the stop-loss never fires and the user's position remains unprotected through the price drop.
**Insight:** When auditing order/trigger validation, check whether the straddle condition still holds after the trigger is crossed in one direction; a strict straddle requirement turns a protective order into a permanently reverting one during fast moves or oracle outages.
