Lavarage — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Lavarage, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 7
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 7 closed, publicly disclosed Lavarage 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 Oracle manipulation, Logic error, Front-running / MEV, Access control, across Solana-Rust, 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
- Oracle manipulation findings disclosed against Lavarage
- Logic error findings disclosed against Lavarage
- Front-running / MEV findings disclosed against Lavarage
- Access control findings disclosed against Lavarage
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Lavarage: A borrower can borrow SOL without backing it by a collateral
Lavarage, a Solana lending program, fails to validate that collateral deposits are tied to the specific borrowing position they fund. Because the borrow instruction only checks that an addCollateral instruction exists in the same transaction without verifying the two reference the same position account, a borrower can open two positions but route both collateral transfers to the first position. Repaying the first position then permits withdrawing both collaterals, leaving the second position's loan fully unbacked — a direct theft of lender SOL. The report includes a passing Anchor test proving the extraction.
Lavarage: Small loans will never be liquidated, generating bad debt for lenders
Lavarage's borrow flow lacks a minimum position-size requirement, so a borrower can open many dust-sized loans against the same pool in a single chained transaction, obtaining the same total principal while paying only one gas fee. When these positions cross the 90% LTV liquidation threshold, a liquidator must spend a separate transaction per position, and because each tiny position's liquidation incentive is smaller than its transaction gas cost, rational liquidators will skip them. The positions therefore accrue as permanent bad debt, causing a net loss for lenders and turning a liquidation-incentive mechanism into a griefing vector.
Lavarage: Borrowers can avoid the payment of an interest share fee by setting themselves as a `fee_receipient`
Lavarage's repay_sol routine deducts a 20% interest-share fee from a borrower's accumulated interest and forwards it to a fee_receipient account. That destination is entirely caller-supplied: it is declared as an UncheckedAccount with no validation tying it to a protocol-owned or operator-set address, and the transfer instruction simply sends interest_share to whatever public key the borrower passes. A borrower can therefore populate fee_receipient with a key they control, so the fee transfer executes back into their own wallet rather than to the protocol's designated recipient, effectively voiding the fee and depriving the intended beneficiary of its revenue. The recommended mitigation is to make the recipient an immutable property of the Pool struct set at pool creation.
Lavarage: Collateral can be claimed back without repaying its corresponding loan due to insufficient instruction validation
The Lavarage protocol is susceptible to a collateral withdrawal bypass vulnerability due to insufficient validation of account contexts in its loan repayment logic. An attacker can construct a malicious transaction that links the withdrawal of collateral from one borrow position to the repayment of a different, dust-sized position. This allows users to claim collateral without fulfilling the original loan obligations, enabling the drainage of trading pools.
Lavarage: Innocent borrower could incur losses caused by a malicious lender
The Lavarage protocol is vulnerable to a front-running attack where lenders can maliciously increase interest rates to harm borrowers. Because interest rates are managed at the global trading pool level and the protocol mandates a minimum of one day's interest, a lender can front-run a borrowing transaction to spike the rate. This forces the borrower to pay the higher, inflated interest rate for at least one full day, even if the position is repaid immediately. This flaw essentially allows lenders to extract value from borrowers through unfavorable, last-minute parameter adjustments.
Lavarage: Lack of freeze authority check for collateral tokens on create trading pool
Lavarage's lending flow accepts SPL tokens as collateral, moving tokens between a borrower account and a protocol PDA on borrow and repay. The integration never verifies whether the collateral token's mint carries an active freeze_authority. Because a freeze_authority can render any token account (including the protocol's position PDA) unusable via FreezeAccount, the token issuer can lock funds and block borrow or repay transfers, and if the authority is later set to None, frozen accounts stay frozen permanently. The recommended fix is to reject any collateral mint whose freeze_authority is not None at trading-pool creation.