reNFT — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for reNFT, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 23
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 23 closed, publicly disclosed reNFT reports indexed on CoinBuggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Access control, Front-running / MEV, Reentrancy, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against reNFT
- Access control findings disclosed against reNFT
- Front-running / MEV findings disclosed against reNFT
- Reentrancy findings disclosed against reNFT
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
reNFT: The owners of a rental safe can continue to use the old guard policy contract for as long as they want, regardless of a new guard policy upgrade
reNFT's Guard.sol policy can be upgraded via Kernel governance, but existing rental safes must individually delegate-call a temporary migration contract to update their stored guard address. A rental safe owner can simply never perform that migration, leaving the safe permanently pointed at the now-deactivated old guard. Because Guard.sol's transaction checks (checkTransaction, _checkTransaction, _revertSelectorOnActiveRental, _revertNonWhitelistedExtension) only read access-control-free view functions on Storage.sol and never verify that the guard itself is still an active Kernel policy, the stale guard keeps approving transactions the new guard would revert. This lets some safe owners bypass newly enforced restrictions indefinitely, creating uneven safety guarantees across safes. The judge downgraded the finding from High to Medium, and reNFT's subsequent mitigation (PR #12 adding an isActive check) was itself flagged as containing an error.
reNFT: `Guard::checkTransaction` restricts native ETH transfer from user's safes
reNFT's Guard contract requires every transaction leaving a rental safe to carry at least 4 bytes of calldata so a function selector is present. Native ETH transfers use empty calldata, so the guard reverts them with GuardPolicy_FunctionSelectorRequired, permanently trapping any ETH that protocol users or hooks deposit into rental safes. Since Gnosis Safes receive ETH by default via their receive() function, this turns a legitimate withdrawal into a lasting denial-of-service on the safe's native balance. The sponsor confirmed it as a valid medium and shipped a fix allowing zero-length calldata for native transfers, which was subsequently confirmed by mitigator reports.
reNFT: Blacklisted extensions can't be disabled for rental safes
reNFT's Safe guard applies its extension whitelist check symmetrically to both enabling and disabling Safe modules. As a result, once a module that was whitelisted is later blacklisted by protocol admins, the safe owner can no longer disable it, leaving the safe permanently exposed to any vulnerability in that module. The finding includes a full Foundry proof-of-concept that enables two extensions, blacklists them, then demonstrates the disableTransaction reverting. The sponsor confirmed the issue and marked the suggested mitigation as unmitigated.
reNFT: Blocklisting in payment ERC20 can cause rented NFT to be stuck in Safe
In reNFT, stopping a rental is a single atomic operation that returns the rented NFT to the lender while simultaneously settling ERC20 rental payments. Payment settlement relies on a strict-transfer helper that reverts on failure, so if the renter, lender, or escrow contract is blocklisted in a USDC/USDT-style payment token, the entire stop transaction reverts. The consequence is that the NFT remains stuck inside the renter's Safe and the escrowed payment is never released, permanently griefing the rental. The sponsor confirmed the finding and the judge adjudicated it as Medium severity.
reNFT: Escrow contract can be drained by creating rentals that bypass execution invariant checks
reNFT's Create policy validates that rental orders' assets reach the expected recipients (Escrow for ERC20, Safe wallet for NFTs) only via Seaport's computed totalExecutions array. A malicious actor can craft a matching PAY/PAYEE order pair where every offer and consideration comes from the same address, so the forked Seaport produces an empty executions array and performs no transfers at all. Because _executionInvariantChecks() is skipped when there are no executions, Create still records the rental in STORE and increments the PaymentEscrow deposit as if a payment had been made. After the fake rental is registered, the attacker stops the rent and the escrow pays out an ERC20 amount that was never actually deposited, draining the escrow contract of whatever matching tokens it holds. The sponsor confirmed the issue and mitigated it with an intermediary transfer so assets are not committed to the rental until they are actually moved.
reNFT: Protocol does not implement EIP712 correctly on multiple occasions
reNFT's Signer library computes EIP-712 hashes non-canonically, causing the protocol's internally derived type hashes to diverge from what standard EIP-712 tooling and integrators produce. The RentalOrder type hash is built via abi.encode of the concat struct-type strings rather than keccak of the packed concatenation, and Hook hashes encode the dynamic extraData field directly instead of pre-hashing it with keccak256 into a 32-byte word. As a result, valid external signatures can be rejected and affected rental flows denied service. The report includes a forge test reproducing the divergence and a fix diff.
All reports in this group
- reNFT: A malicious borrower can hijack any NFT with `permit()` function he rents.Access control$0
- reNFT: All orders can be hijacked to lock rental assets forever by tipping a malicious ERC20Front-running / MEV$0
- reNFT: `RentPayload`'s signature can be replayedLogic error$0
- reNFT: Lender of a PAY order lending can grief renter of the paymentLogic error$0
- reNFT: Assets in a Safe can be lostLogic error$0
- reNFT: DoS of Rental stopping mechanismLogic error$0
- reNFT: Risk of DoS when stoping large rental orders due to block gas limitLogic error$0
- reNFT: An attacker can hijack any ERC1155 token he rents due to a design issue in reNFT via reentrancy exploitationReentrancy$0
- reNFT: Incorrect ordering for deletion allows to flash steal rented NFT'sLogic error$0
- reNFT: Incorrect `gnosis_safe_disable_module_offset` constant leads to removing the rental safe's `module` without verificationAccess control$0
- reNFT: Malicious actor can steal any actively rented NFT and freeze the rental payments (of the affected rentals) in the `escrow` contractLogic error$0
- reNFT: paused ERC721/ERC1155 could cause stopRent to revert, potentially causing issues for the lender.Logic error$0
- reNFT: 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.Logic error$0
- reNFT: DOS possible while stopping a rental with erc777 tokensLogic error$0
- reNFT: Attacker can lock lender NFTs and ERC20 in the safe if the offer is set to partialLogic error$0
- reNFT: Upgrading modules via `executeAction()` will brick all existing rentalsLogic error$0
- reNFT: An attacker is able to hijack any ERC721 / ERC1155 he borrows because guard is missing validation on the address supplied to function call `setFallbackHandler()`Access control$0