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
- 4
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 4 closed, publicly disclosed reNFT reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Front-running / MEV, Access control, 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
- Front-running / MEV findings disclosed against reNFT
- Access control 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: 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: All orders can be hijacked to lock rental assets forever by tipping a malicious ERC20
reNFT's Create contract acts as a Seaport zone that validates and stores orders as rentals when fulfilled. Because Seaport derives the order hash using only the totalOriginalConsiderationItems count, an order fulfiller can extend the consideration array at fulfillment time with extra ERC20 items (Seaport 'tipping') without invalidating the signing. The zone's validateOrder does not tie the signed RentPayload to consideration items, so a malicious fulfiller can append an ERC20 that reverts on transfer; when the rental is later stopped, the escrow transfer of that tipped token always reverts, so rented assets remain locked in the rental safe indefinitely. The finding includes a reproduction with a MockRevertOnTransferERC20 and a forge test, and was confirmed and mitigated by reNFT via token whitelisting.
reNFT: Incorrect `gnosis_safe_disable_module_offset` constant leads to removing the rental safe's `module` without verification
reNFT's RentalConstants library hard-codes a calldata offset for Gnosis Safe's disableModule(address prevModule, address module) at 0x24, which points at the first parameter (prevModule) rather than the module intended for removal (which requires 0x44). Because Guard._checkTransaction extracts and whitelist-verifies whatever contract address sits at that offset before allowing the safe transaction, the wrong address gets validated. As a result, a safe owner can remove a whitelisted module such as the protocol's policy contract without reNFT's authorization guard ever rejecting it, enabling the rental safe to be reconfigured in ways that bypass protocol controls. The bug was confirmed by reNFT, fixed by correcting the offset to 0x44, and the mitigation was subsequently verified.
reNFT: `RentPayload`'s signature can be replayed
reNFT's Create#validateOrder verifies a PayRentPayload signature only against its expiration timestamp and the derived hash of the payload metadata, with no nonce or binding to the specific order being fulfilled. Because OrderMetadata is simple and not unique per order, a malicious renter can reuse one unexpired payload and signature to fulfill every PAY order that carries identical metadata, accumulating rental earnings from multiple lenders via a single signed payload. The finding includes a PoC test demonstrating three different lenders creating PAY orders that all end up with identical extraData, confirming the replay. The team mitigated the issue by adding an order-binding field and disallowing partial Seaport orders.