LEND — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for LEND, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 19
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 19 closed, publicly disclosed 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 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
- Logic error findings disclosed against LEND
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
LEND: Incorrect LEND reward distribution for cross-chain borrows
In the LEND protocol's distributeBorrowerLend() reward function, the borrow amount used to compute LEND rewards is read from borrowWithInterest(), which only accounts for cross-chain borrows that originated on the current chain (crossChainBorrows), rather than borrows actually executed on this chain regardless of origin. This means users who borrowed on-chain using collateral from another chain (recorded in crossChainCollaterals) are excluded from rewards, while users whose debt was executed on a different chain still accrue local rewards. The mis-assignment under-rewards genuine local borrowers and over-rewards borrowers of other chains, distorting the incentive distribution and potentially paying rewards for debt not held on this chain.
LEND: Transfers will fail when using USDT
LEND V2's CoreRouter::borrow sends borrowed tokens to the user via a raw IERC20(_token).transfer() call that asserts a boolean return value. Tokens such as USDT that deviate from the ERC20 standard return no boolean, so the call reverts on ordinary usage, permanently blocking borrows in those tokens. Because borrow is a primary entry point, this constitutes a medium-severity denial of service rather than an accounting or access-control flaw. The prescribed fix is to route transfers through OpenZeppelin's SafeERC20.safeTransfer.
LEND: The liquidation validation logic is wrong
During a cross-chain liquidation in the LEND V2 protocol, the source chain computes the number of collateral tokens to seize via `liquidateCalculateSeizeTokens` and forwards that seize amount to the destination chain as the cross-chain message payload. On the receiving chain, `_checkLiquidationValid` mistakenly passes this seize amount as the `borrowAmount` argument to `getHypotheticalAccountLiquidityCollateral`. Because the gate then asks whether hypothetically borrowing that many additional tokens would make the account undercollateralized — rather than validating the actual collateral dynamics — a healthy position can be falsely flagged as liquidatable and forcibly liquidated without any real additional borrow occurring. The fix replaces the passed `borrowAmount` with 0 so validation only tests the borrower's real existing borrow state.
LEND: `CoreRouter.sol`’s `repayBorrowInternal` incorrectly updates `same chain` borrow balances on `cross chain` repayments
LEND's CoreRouter.sol implements cross-chain and same-chain lending on top of LayerZero messaging. In repayBorrowInternal, the repayment math branches on _isSameChain to choose which recorded borrow amount to settle, but the subsequent block that updates or removes lendStorage.borrowBalance runs unconditionally. As a result, repaying a cross-chain loan with _isSameChain set to false still deletes or reduces the borrower's same-chain borrow record for the same lToken, even when that same-chain debt is independent and still outstanding. This can wipe legitimate same-chain borrows, leaving lenders on that chain holding unbacked positions and suffering direct fund loss. The provided fix guards the same-chain borrow-update block with an _isSameChain check so cross-chain repayments never touch same-chain state.
LEND: Multiple Cross-Chain borrows using same collateral
LEND's cross-chain borrowing flow fails to lock a user's collateral on the source chain before emitting a LayerZero V2 borrow message. The collateral is only hypothetically validated via getHypotheticalAccountLiquidityCollateral and permanently registered only after the destination chain's confirmation returns. Because the collateral is not reserved during the in-flight window, a user can send multiple borrowCrossChain calls in one block, and each independent destination chain approves borrowing up to the full collateral value. The result is aggregate debt that exceeds what the collateral can back, and the protocol absorbs the over-borrowed portion — a loss that grows linearly with the number of destination chains.
LEND: Cross-chain borrow ignores existing debt in collateral validation
LEND's cross-chain borrow flow in CrossChainRouter.sol miscalculates the collateral that authorizes a destination-chain borrow. When a user borrows across chains via LayerZero, the source chain reads only the raw collateral figure from getHypotheticalAccountLiquidityCollateral and transmits it, discarding the parallel totalBorrowed result. The destination chain then permits any borrow whose amount is below that gross collateral value, so a user can effectively borrow against the same collateral on multiple chains at once. In the documented example a user with 1000 USDC collateral (80% factor = $800 capacity) borrows $600 on the source chain and a further $700 cross-chain, reaching 162.5% utilization. This systemic undercollateralization creates unliquidatable positions and can drain protocol reserves, so the fix is to transmit net available borrowing capacity (collateral minus existing borrows) rather than gross collateral.
All reports in this group
- LEND: Cross-chain collaterals are wrongly calculated in the borrowWithInterest functionLogic error$0
- LEND: User can redeem collateral immediately after initiating the borrow, leading undercollateralization.Logic error$0
- LEND: Cross-chain liquidation uses incorrect lToken address, preventing repayment and breaking liquidation flowLogic error$0
- LEND: Incorrect Debt Tracking in `_updateRepaymentState`Logic error$0
- LEND: Subsequent Cross‐Chain Borrows don’t Accrue interest on existing principal when borrowing the same AssetLogic error$0
- LEND: Borrower will loose funds if their repay transaction executes after cross-chain liquidation callLogic error$0
- LEND: Drainage of the LEND token reserves through repeated claims of the same rewardsLogic error$0
- LEND: Incorrect Collateral Check Logic in CoreRouter.sol#borrow()Logic error$0
- LEND: wrong calculation of amount of Ltokens to seize in liquidateCrossChain functionLogic error$0
- LEND: Protocol rewards tokens permanently stuckLogic error$0
- LEND: Liquidators Must Supply Collateral Asset Before Redeeming Seized RewardsLogic error$0
- LEND: Cross-Chain liquidation uses collateral seize amount instead of repayment amount for debt reductionLogic error$0
- LEND: User may not be able to borrow even if they provide sufficient collateralsLogic error$0