Revert Lend — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Revert Lend, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 28
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 28 closed, publicly disclosed Revert Lend 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 Access control, Oracle manipulation, Reentrancy, Front-running / MEV, Logic error, 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
- Access control findings disclosed against Revert Lend
- Oracle manipulation findings disclosed against Revert Lend
- Reentrancy findings disclosed against Revert Lend
- Front-running / MEV findings disclosed against Revert Lend
- Logic error findings disclosed against Revert Lend
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Revert Lend: `V3Utils.execute()` does not have caller validation, leading to stolen NFT positions from users
A missing caller validation in Revert Lend's `V3Utils.execute()` function allows unauthorized accounts to execute arbitrary operations on approved Uniswap V3 position NFTs. Because interaction with `V3Utils` requires a two-step process—first approving the utility contract on the NonfungiblePositionManager and then calling `execute()`—approved positions are vulnerable to front-running. An attacker can back-run the owner's approval call and trigger `V3Utils.execute()` with custom parameters that drain all underlying liquidity and route the proceeds to the attacker's wallet, resulting in complete theft of the position's assets.
Revert Lend: `V3Oracle` susceptible to price manipulation
The V3Oracle contract in Revert Lend relies on the manipulated-prone slot0 spot price from Uniswap V3 pools to calculate the token breakdown of liquidity positions. While the protocol uses secure price feeds like Chainlink and TWAP for asset valuation, it uses the untrusted spot price to determine how much liquidity belongs to each token in a position. This allows an attacker to manipulate the spot price via flash loans, skewing the reported collateral value and enabling unauthorized borrowing or incorrect liquidations.
Revert Lend: Risk of reentrancy `onERC721Received` function to manipulate collateral token configs shares
A reentrancy vulnerability in Revert Lend's V3Vault smart contract allows malicious borrowers to artificially inflate internal collateral debt share accounting during Uniswap V3 position transformations. When transforming a position, `V3Vault.onERC721Received` triggers an external call to return the old NFT prior to finalizing state updates for the new position token. An attacker can hijack execution via the ERC721 transfer callback to call `borrow`, causing internal debt counters (`totalDebtShares`) to double-count debt additions. By repeatedly executing this sequence, an attacker can exceed the protocol's collateral value limit, permanently blocking legitimate users from borrowing and disabling interest accrual.
Revert Lend: `AutoRange` execution can be front-ran to avoid protocol fee, causing loss for protocol
In Revert Lend's `AutoRange` contract, position owners can select between two fee structures: taking 0.15% of the total position size or taking 2% of collected fees. Off-chain operators trigger automated position adjustments by supplying a `rewardX64` parameter configured according to the user's current fee choice. A vulnerability exists because position owners can front-run the operator's execution transaction to alter their fee selection flag in storage while the operator's supplied `rewardX64` remains fixed. This enables position owners to force the contract to apply the lower 0.15% rate solely to collected fees, allowing them to systematically evade protocol fees and cause economic loss to the protocol.
Revert Lend: `V3Vault::transform` does not validate the `data` input and allows a depositor to exploit any position approved on the transformer
A parameter validation flaw in Revert Lend's `V3Vault.transform()` allows any vault position owner to execute arbitrary actions on external positions delegated to Revert transformers. When calling `transform()`, `V3Vault` validates vault ownership for the `tokenId` argument provided directly in the caller's function signature, but fails to check whether the `tokenId` encoded inside the `data` calldata matches it. An attacker can pass their own valid vault token ID to bypass vault authorization while encoding a target user's external position token ID inside the calldata. This grants unauthorized attackers the ability to trigger transformer logic on non-vault positions, enabling them to siphon reward fees or trigger unfavorable swaps that result in severe loss of user funds.
Revert Lend: Users' newly created positions can be prematurely closed and removed from the vault directly after they are created
In Revert Lend's `V3Vault`, creating a new position or transferring an NFT collateral instantiates a loan position with zero initial debt shares. The `_repay` internal function failed to require a non-zero repayment amount or check that the target loan possessed active debt. As a result, an attacker could invoke `repay` with a zero amount on any newly initialized position, causing the protocol logic to evaluate `0 == 0` debt shares and treat the position as fully paid off. The vault then executed `_cleanupLoan`, returning the collateral NFT to the user and deleting the loan record, effectively preventing the user from borrowing against their position until they re-deposited the NFT.
All reports in this group
- Revert Lend: Owner of a position can prevent liquidation due to the `onERC721Received` callbackReentrancy$0
- Revert Lend: `DailyLendIncreaseLimitLeft` and `dailyDebtIncreaseLimitLeft` are not adjusted accuratelyLogic error$0
- Revert Lend: `AutoExit` could receive a reward calculated from the entire position's fund even if `onlyFee` is true in `AutoExit.execute()`Logic error$0
- Revert Lend: An attacker can easily bypass the collateral value limit factor checksLogic error$0
- Revert Lend: `dailyDebtIncreaseLimitLeft` is not updated in `liquidate()`Logic error$0
- Revert Lend: Lack of safety buffer in `_checkLoanIsHealthy` could subject users who take out the max loan into a forced liquidationOracle manipulation$0
- Revert Lend: Wrong global lending limit check in `_deposit` functionLogic error$0
- Revert Lend: Large decimal of `referenceToken` causes overflow at oracle price calculationOracle manipulation$0
- Revert Lend: `setReserveFactor` fails to update global interest before updating reserve factorAccess control$0
- Revert Lend: No `minLoanSize` means liquidators will have no incentive to liquidate small positionsLogic error$0
- Revert Lend: Users can lend and borrow above allowed limitationsLogic error$0
- Revert Lend: Repayments and liquidations can be forced to revert by an attacker that repays minuscule amount of sharesFront-running / MEV$0
- Revert Lend: `V3Vault` is not ERC-4626 compliantLogic error$0
- Revert Lend: `V3Vault.sol` permit signature does not check receiving token address is USDCSignature replay$0
- Revert Lend: Tokens can't be removed as a collateral without breaking liquidations and other core functionsOracle manipulation$0
- Revert Lend: Users's tokens stuck in `AutoCompound` after Vault is deactivatedReentrancy$0
- Revert Lend: User might execute `PositionToken` of token set by previous token ownerAccess control$0
- Revert Lend: Due to interest rates update method, Interest-Free Loans are possible and the costs of DoS are reducedFlash loan attack$0
- Revert Lend: Incorrect liquidation fee calculation during underwater liquidation, disincentivizing liquidators to participateLogic error$0
- Revert Lend: Liquidation reward sent to msg.sender instead of recipientLogic error$0
- Revert Lend: Users cannot stop loss in AutoRange and AutoExitOracle manipulation$0
- Revert Lend: `_getReferencePoolPriceX96()` will show incorrect price for negative tick deltas in current implementation cause it doesn't round up for themOracle manipulation$0