# Attacker can lock lender NFTs and ERC20 in the safe if the offer is set to partial

Partial-fill Seaport orders produce identical rental order hashes, so a renter's second partial fill overwrites storage and locks half the lender's NFTs/ERC20.

- Payout: Contest reward
- Severity: high
- Program: reNFT
- Credited: said
- Disclosed: 2024-03-20
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-01-renft-findings/issues/203
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AH-07
- Tags: domain:web3 impact:dos impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Seaport zone Create policy / Storage module rental order hashing
**Root cause:** _deriveRentalOrderHash omits a nonce and per-fill amounts, so two partial fills of the same Seaport order hash to the same rental order hash; addRentals overwrites and removeRentals deletes the single entry, leaving residual rentedAssets locked.
**Steps:**
1. Create a PAY offer with PARTIAL_RESTRICTED order type (2 ERC1155 + 100 ERC20).
2. Fulfill twice via matchAdvancedOrders with partial fills (1 ERC1155 + 50 ERC20 each), each producing the same seaportOrderHash and thus same rental order hash.
3. Both fills call STORE.addRentals with the same hash; second overwrites first.
4. After expiry, call stopRent on first order: removeRentals deletes orders[hash] and decrements rentedAssets by only one fill's amounts.
5. Second stopRent reverts with StorageModule_OrderDoesNotExist; remaining 1 ERC1155 + 50 ERC20 stay locked in the safe.
**How found:** Reading _rentFromZone and _deriveRentalOrderHash, noticed the hash lacks a nonce and per-fill amounts, so partial fills of the same Seaport order collide; confirmed via a modified forge test with PARTIAL_RESTRICTED orders.
**Exploitation:** Attacker (renter) fills a partial-fill lender offer in two halves referencing the same Seaport order hash. On stopRent only one half is returned; the other half remains locked in the attacker's safe and the rental cannot be stopped again.
**Insight:** When a protocol derives its own order hash from an external marketplace order, check whether partial fills or repeated fulfillment of the same external order hash can collide in internal storage keyed by that hash.