# A malicious lender can freeze borrower's ERC1155 tokens indefinitely because the guard can't differentiate between rented and non-rented ERC1155 tokens in the borrower's safe.

reNFT Guard blocks all ERC1155 transfers of a rented token ID, so a malicious lender's reverting onERC1155Receive hook freezes the borrower's own tokens of that ID indefinitely.

- Payout: Contest reward
- Severity: medium
- Program: reNFT
- Credited: sin1st3r\_\_
- Disclosed: 2024-03-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-renft-findings/issues/600
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AM-01
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:chained technique:source-review vuln:access-control vuln:business-logic vuln:dos

**Target:** Gnosis Safe Guard policy (Guard.sol) on rental safes
**Root cause:** Guard._revertSelectorOnActiveRental checks only token address and ID for ERC1155 safeTransferFrom, not whether the specific tokens are rented, so any active rental of that ID blocks transfers of the borrower's unrented tokens of the same ID. Stop/Reclaimer uses safeTransferFrom to return tokens, so a lender whose onERC1155Receive reverts prevents rental finalization.
**Steps:**
1. Borrower holds 1000 unrented ERC1155 tokens of id 5 in their rental safe.
2. Borrower rents 10 tokens of the same id 5 from malicious lender contract for 10 days.
3. Lender contract implements onERC1155Receive() that reverts until a chosen time.
4. After expiry, borrower calls stopRent(); Reclaimer's safeTransferFrom to lender triggers reverting hook, so stopRent reverts.
5. Rental stays active; Guard blocks any safeTransferFrom of id 5 from the safe, freezing the borrower's 1000 unrented tokens.
6. Run `forge test --match-contract Exploit --match-test test_ERC1155_Freeze_Exploit -vv` with provided SetupExploit.sol/Exploit.sol.
**How found:** Code reading of Guard.sol's ERC1155 branch: noticed _revertSelectorOnActiveRental keys only on (from, to, tokenId) with no per-rental accounting, then reasoned that Stop's Reclaimer uses safeTransferFrom, making rental finalization hostage to the receiver hook.
**Exploitation:** Attacker lists an ERC1155 rental order for a token ID the victim already holds in quantity, waits for the victim to rent a small amount, then keeps the onERC1155Receive hook reverting so stopRent can never finalize; the victim's pre-existing tokens of that ID remain locked in the safe until the attacker relents.
**Insight:** When a guard keys restrictions on (token, id) rather than on the specific rented units, look for any path where the counterparty controls a callback (ERC1155/ERC721 receiver hooks, ERC777 hooks) that can block the unwind path and thereby extend the restriction to unrelated user assets.