# Existing user’s locked JPEG could be overwritten by new user, causing permanent loss of JPEG funds

JPEGLock positions keyed by NFT index get overwritten when a second user finalizes a value proposal, permanently locking the first user's JPEG.

- Payout: Audit contest
- Severity: high
- Program: JPEG'd
- Found by: hickuphh3
- Disclosed: 2022-06-10
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-04-jpegd-findings/issues/10
- Library page: https://bugbountylibrary.com/r/c4%3A2022-04-jpegd%3AH-02
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:business-logic

**Target:** NFTVault / JPEGLock Solidity contracts
**Root cause:** JPEGLock.lockFor() writes positions[_nftIndex] without checking or releasing an existing position, so a new finalization for the same NFT index replaces the prior owner's lock record.
**Steps:**
1. Mint NFT index 7000 to user; dao sets pending NFT value via `setPendingNFTValueETH(index, 50e18)`
2. user approves locker and calls `finalizePendingNFTValueETH(index)`, creating lock position owned by user
3. dao sets new pending value `setPendingNFTValueETH(index, 100e18)`
4. owner approves locker and calls `finalizePendingNFTValueETH(index)`; `lockFor` overwrites `positions[index]` with owner
5. After 366 days, `locker.connect(user).unlock(index)` reverts with `unauthorized`; user's JPEG permanently stuck
**How found:** Code review of JPEGLock.lockFor() and NFTVault.finalizePendingNFTValueETH() noticing positions mapping is keyed solely by NFT index with no existing-position guard; confirmed via Foundry/Hardhat test.
**Exploitation:** Any user can finalize a value-change proposal for an NFT index that already has a lock schedule, overwriting the stored owner and stranding the prior user's locked JPEG in the contract with no withdrawal path.
**Insight:** When a mapping is keyed by a shared identifier (NFT index) rather than per-user, check every write path for missing overwrite guards; lock/stake contracts that store owner+amount per shared key are prime targets for griefing that permanently strands funds.