# User-supplied slippage for decrease orders is ignored

GMX decrease orders pass minOutputAmount=0 to internal swaps, ignoring user slippage protection and exposing position closes to sandwiching.

- Payout: Contest reward
- Severity: high
- Program: Gmx
- Credited: IllIllI
- Disclosed: 2022-09-22
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2023-02-gmx-judging/issues/138
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-02-gmx%3AH-9
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:business-logic vuln:oracle-manipulation

**Target:** GMX Synthetics DecreasePositionCollateralUtils swap logic
**Root cause:** Internal swaps in DecreasePositionCollateralUtils hardcode minOutputAmount=0, and no downstream check compares final output to the user-supplied minOutputAmount from order creation.
**Steps:**
1. Create a decrease order with a nonzero minOutputAmount.
2. Observe DecreasePositionCollateralUtils.swapProfitToCollateralToken and swapWithdrawnCollateralToPnlToken call swapHandler.swap with minOutputAmount=0.
3. Confirm no check in DecreaseOrderUtils compares final output to the order's minOutputAmount.
4. Attacker sandwiches the swap since zero slippage protection is enforced.
**How found:** Manual code review of the decrease-position collateral swap paths, noticing hardcoded 0 minOutputAmount and absence of a final-output check against the order's minOutputAmount.
**Exploitation:** Attacker observes a pending decrease order and sandwiches the collateral-to-PNL swap, since minOutputAmount=0 allows unlimited slippage, capturing value from the user's close.
**Insight:** When auditing order-based protocols, trace user-supplied slippage parameters all the way into every internal swap call; hardcoded 0 minOutputAmount in helper functions silently disables protection even if the order struct carries it.