# Data corruption in NFTFloorOracle; Denial of Service

NFTFloorOracle's swap-and-pop feeder removal fails to update feederPositionMap indices, corrupting state and reverting later removals, blocking removal of dead feeders.

- Payout: Contest reward
- Severity: high
- Program: ParaSpace
- Credited: Englave
- Disclosed: 2023-04-27
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-11-paraspace-findings/issues/79
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-paraspace%3AH-01
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:dos

**Target:** NFTFloorOracle price-feeder registry (Solidity contract)
**Root cause:** _removeFeeder uses swap-and-pop but does not update feederPositionMap[feeders[feederIndex]].index after moving the last element into the removed slot, leaving stale indices.
**Steps:**
1. Deploy NFTFloorOracle with empty feeders array.
2. `addFeeders([A, B, C])` -> feeders=[A,B,C], positions A=0,B=1,C=2.
3. `removeFeeder(B)`: swap last (C) into index 1, pop; feeders=[A,C] but feederPositionMap[C].index stays 2.
4. `removeFeeder(C)`: reads index 2, accesses feeders[2] out of bounds -> revert.
5. Feeder C can no longer be removed; mapping corrupted.
**How found:** Code reading of the swap-and-pop deletion logic in _removeFeeder; noticed the position map index was not rewritten after the swap, then confirmed with a Solidity PoC.
**Exploitation:** Not attacker-triggered; occurs during normal admin feeder removal. Once a feeder is dead/malfunctioning, removal reverts, leaving a stale price source that can feed incorrect floor prices into the protocol.
**Insight:** When auditing swap-and-pop array deletion, always verify every auxiliary index map is updated for the element moved into the vacated slot, not just the removed one.