# `emergencyClosePosition` can be blocked

PartyA can call requestToClosePosition with 1 wei to flip quote status to CLOSE_PENDING, blocking PartyB's emergencyClosePosition which requires OPENED status.

- Payout: Contest reward
- Severity: medium
- Program: Symmetrical
- Credited: Yuki
- Disclosed: 2023-06-05
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2023-06-symmetrical-judging/issues/236
- Library page: https://bugbountylibrary.com/r/sherlock%3A2023-06-symmetrical%3AM-16
- Tags: domain:web3 impact:dos kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** PartyB emergency close facet (symmio-core)
**Root cause:** emergencyClosePosition requires quote.quoteStatus == OPENED, but PartyA can unilaterally move status to CLOSE_PENDING via requestToClosePosition with minimal quantityToClose.
**Steps:**
1. PartyA calls `PartyAFacetImpl.requestToClosePosition(quoteId, 1 wei, ...)` on an OPENED quote, setting status to CLOSE_PENDING
2. PartyB calls `PartyBFacetImpl.emergencyClosePosition(quoteId, upnlSig)` which reverts on `require(quote.quoteStatus == QuoteStatus.OPENED)`
3. Alternatively PartyA front-runs PartyB's emergencyClosePosition tx with the same requestToClosePosition call
4. PartyB accepts the 1 wei close to restore OPENED, but PartyA front-runs again to re-block
**How found:** Code reading of emergencyClosePosition's state guard combined with knowledge that PartyA controls requestToClosePosition status transitions; recognized front-running/pre-emption griefing vector.
**Exploitation:** Griefing: PartyA pre-emptively or via front-running flips quote status to CLOSE_PENDING, preventing PartyB from emergency-closing positions during emergency mode, delaying risk mitigation.
**Insight:** When a privileged emergency path gates on a state that an untrusted counterparty can unilaterally transition, that counterparty can grief the emergency action; check every state-guard for who else can move the state.