# When private keeper mode is off users can queue orders with the wrong asset

BufferRouter.resolveQueuedTrades never checks the supplied asset matches the queued trade, letting attackers open options at another asset's price and drain LPs.

- Payout: Contest reward
- Severity: high
- Program: Buffer
- Credited: kaliberpoziomka
- Disclosed: 2022-11-11
- Write-up quality: 7/10
- Original: https://github.com/sherlock-audit/2022-11-buffer-judging/issues/85
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-11-buffer%3AH-1
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:high tech:solidity technique:source-review vuln:business-logic vuln:dos vuln:oracle-manipulation

**Target:** BufferRouter.resolveQueuedTrades / _openQueuedTrade
**Root cause:** resolveQueuedTrades validates the price signature but never verifies currentParams.asset equals the queuedTrade's asset; _openQueuedTrade then opens the option using the attacker-supplied price.
**Steps:**
1. Create a call option on asset B (price ~$1) expiring in 10 minutes with 5% slippage.
2. Queue the trade, then call `resolveQueuedTrades` passing `currentParams.asset = assetA` and a valid signed price for asset A (~$0.95).
3. Signature validates, timestamp matches queuedTime, price $0.95 is within slippage of expectedStrike, so `_openQueuedTrade` creates the option with strike $0.95.
4. Option is now in-the-money vs real asset B price $1; repeat across both pools to drain LPs.
**How found:** Code review of resolveQueuedTrades: noticed _validateSigner only binds timestamp/asset/price/signature but the asset is never compared to queuedTrade.targetContract, and _openQueuedTrade trusts the passed price.
**Exploitation:** Attacker queues an option on one asset then resolves it with a signed price from a different, closely-priced asset, producing a mispriced strike that is almost guaranteed profitable, extracting value from LPs; repeated back and forth drains both pools.
**Escalation:** Can also be used to grief: resolving with a wrong asset whose price is far off causes slippage check to fail and the victim's order to be cancelled (DoS).
**Insight:** When a resolve/fill function takes an asset or market identifier as a parameter, check it is cross-referenced against the stored order; a valid signature over (asset,price) is not proof the asset matches the queued trade.