ZeroLend One — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for ZeroLend One, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 24
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 24 closed, publicly disclosed ZeroLend One 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, Oracle manipulation, 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 ZeroLend One
- Access control findings disclosed against ZeroLend One
- Front-running / MEV findings disclosed against ZeroLend One
- Oracle manipulation findings disclosed against ZeroLend One
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
ZeroLend One: Using the same heartbeat for multiple price feeds, causing DOS
ZeroLend One's price-fetch path hardcodes a single 30-minute heartbeat in PoolGetters::getAssetPrice and applies it uniformly to every asset on every chain, even though Chainlink feeds use chain- and pair-specific heartbeat intervals such as ~24 hours for USDT/USD on Linea. This causes the protocol's staleness guard to fire spuriously during normal feed inactivity, reverting ordinary operations like collateral withdraws and producing sustained denial of service on affected chains; conversely the loose threshold on fast-updating chains risks accepting stale prices. The proposed fix is to bind each oracle to its own configurable heartbeat parameter so freshness is checked against the actual feed schedule.
ZeroLend One: CuratedVaults are prone to inflation attacks due to not utilising virtual shares
ZeroLend One's CuratedVault ERC-4626 wrapper sets VIRTUAL_SHARES and VIRTUAL_ASSETS to zero in SharesMathLib, diverging from the Morpho-blue code it derives from, leaving vaults vulnerable to the classic first-depositor inflation attack. An attacker can front-run the first deposit in a fresh vault position, inflate the share price with a donation plus a 1e18+1 own deposit that mints a single share, and thereby cause a subsequent legitimate depositor's contribution to round down to zero shares. The attacker ends up controlling the only outstanding share and can redeem it for nearly all vault assets including the victim's funds. Sherlock upheld the finding as Medium severity with duplicates after rejecting an invalid-claim escalation, even while noting the attacker also suffers some loss.
ZeroLend One: A Reserve Borrow Rate can be significantly decreased after liquidation
ZeroLend One is an Aave-forked lending protocol. During a liquidation, the reserve's cached nextDebtShares value is overwritten with the number of debt shares burned rather than the total shares remaining after the burn. Because that incorrect value feeds the interest-rate strategy, the reserve's borrow rate collapses proportionally to how little debt the liquidator covered, allowing a malicious borrower to drive an unhealthy position into a much cheaper borrowing state and repay at an artificially reduced rate.
ZeroLend One: An attacker can hijack the `CuratedVault`'s matured yield
ZeroLend One's CuratedVault computed totalAssets by reading each underlying pool's position balance through a view function that never advances the pool's liquidityIndex. Because accrued yield was not booked before pricing shares, depositors got shares minted against the stale pre-accrual asset figure. An attacker could flash-loan a large deposit, receive underpriced shares, redeem immediately, and capture a pro-rata share of matured yield at existing suppliers' expense. The Sherlock judge accepted an escalation and upheld this as High with duplicates; the fix forces the pool reserve to update at the start of totalAssets().
ZeroLend One: Inconsistent Application of Reserve Factor Changes Leads to Protocol Insolvency Risk
ZeroLend One, an Aave-fork lending protocol, lets the pool factory owner change a global `reserveFactor` that applies across every pool at once. When this parameter changes, the reserve accounting routine applies the new factor to treasury share minting while the liquidity index update still reflects the prior cached rate, so the treasury accrues a share of interest that was never actually earned by the pool. The mismatch means increasing the factor over-mints treasury shares (leaving insufficient assets for user withdrawals and eventually breaking withdrawals), while decreasing it under-mints shares that permanently lock funds in the contract. The finding includes a concrete PoC test and was upheld as Medium with duplicates after the escrow/rules escalation was rejected by the judging team.
ZeroLend One: Full Liquidation Won't Sweep the Whole Debts With Leaving Some, And Will Wrongly Set Borrowing as False
ZeroLend One's liquidation path confuses debt shares with debt assets. The liquidate() debtToCover parameter is documented as assets, but _calculateDebt() returns raw debtShares and userCollateralBalance is fed in as supplyShares without any index-based conversion, so the entire flow treats share counts as asset amounts. A liquidator attempting full liquidation therefore repays fewer debt units than intended and, because the equality check compare userDebt against actualDebtToLiquidate fires on the share values, the protocol wrongly flips the debt asset's borrowing flag to false. The PoC demonstrates ~9.07e18 debtShares remaining after a purported full liquidation while isBorrowing becomes false, corrupting total debt, LTV and health factor calculations across the pool.
All reports in this group
- ZeroLend One: The rewards distribution in the NFTPositionManager is unfairLogic error$0
- ZeroLend One: Function `executeMintToTreasury` will incorrectly reduce the `supplyShares`, therefore prevent the last users from withdrawingLogic error$0
- ZeroLend One: Interest rate is updated before updating the debt when repaying debtLogic error$0
- ZeroLend One: `CuratedVaultSetters::_supplyPool()` does not consider the pool cap of the underlying pool, which may cause `deposit()` to revert or lead to an unintended reordering of `supplyQueue`Logic error$0
- ZeroLend One: The repayment process in the NFTPositionManager can sometimes be revertedLogic error$0
- ZeroLend One: Malicious actors can execute sandwich attacks during market addition with existing fundsFront-running / MEV$0
- ZeroLend One: Liquidated positions will still accrue rewards after being liquidatedLogic error$0
- ZeroLend One: NFTPositionManager's `repay()` and `repayETH()` are unavailable unless preceded atomically by an accounting updating operationLogic error$0
- ZeroLend One: `GenericLogic.sol` contract assumes all price feeds has the same decimals but is a wrong assumption that leads to an incorrect health factor math.Oracle manipulation$0
- ZeroLend One: Liquidation can be DOSed due to lack of liquidity on collateral asset reserveLogic error$0
- ZeroLend One: Unclaimable reserve assets will accrue in a pool due to the difference between interest paid on borrows and interest earned on suppliesLogic error$0
- ZeroLend One: After a User withdraws The interest Rate is not updated accordingly leading to the next user using an inflated index during next deposit before the rate is normalized againLogic error$0
- ZeroLend One: Malicious pool deployer can set a malicious interest rate contract to lock funds of vault depositorsLogic error$0
- ZeroLend One: Wrong calculation of supply/debt balance of a position, disrupting core system functionalitiesLogic error$0
- ZeroLend One: Position Risk Management Functionality Missing in Position Manager and dos in certain conditionsLogic error$0
- ZeroLend One: Curated Vault allocators cannot `reallocate()` a pool to zero due to attempting to withdraw 0 tokens from the underlying poolLogic error$0
- ZeroLend One: `LiquidationLogic@_burnCollateralTokens` does not account for liquidation fees when withdrawing collateral during liquidation leading to incorrect accounting and Pools insolvencyLogic error$0
- ZeroLend One: Supply interest is earned on `accruedToTreasuryShares` resulting in higher than expected treasury fees and under rare circumstances DOSed pool withdrawalsLogic error$0