Solana and Rust program vulnerabilities in disclosed reports
Solana's account model moves the security burden from call ordering to account validation — the bugs look nothing like their EVM equivalents.
- Reports indexed
- 10
- Total paid
- $600k
- Critical
- 1
- Largest payout
- $600k
Solana programs are stateless code operating over accounts the caller supplies, which makes account validation the entire security boundary. The dominant bug class is a missing check: an account that is never verified as owned by the expected program, a signer flag never asserted, or a PDA derived without confirming the bump and seeds.
Type confusion is the second cluster. Two account structs with compatible layouts can be substituted for one another unless a discriminator is checked, which is precisely what Anchor's account discriminators exist to prevent — and precisely what raw programs and `AccountInfo` escape hatches skip.
Arithmetic differs too: Rust release builds wrap silently on overflow unless checked arithmetic is used explicitly, so the overflow class that Solidity 0.8 retired is still live here.
What reviewers look for
- Accounts used without an owner check against the expected program
- Missing `is_signer` assertions on authority accounts
- PDA derivation without canonical bump verification
- Type confusion between structurally similar account layouts
- Unchecked arithmetic in release builds
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Missing owner check on Solana instruction lets attacker drain vault
A missing program ownership check in a Solana yield vault protocol allowed unauthorized account spoofing during withdrawal processing. Because the instruction handler accepted an unchecked account and verified only a discriminator byte rather than validating account ownership, an attacker could supply a custom state account with manipulated fields. The protocol trusted the forged state data and generated a Program Derived Address (PDA) signature to execute a token transfer, enabling complete draining of the protocol's vault funds.
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: 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.
Olas: Withdraw amount returned by `getLiquidityAmountsAndPositions` may be incorrect
The Olas liquidity lockbox contract contains a logic error in its getLiquidityAmountsAndPositions view function, which is intended to calculate the necessary parameters for user withdrawals. When a withdrawal request requires only a portion of the liquidity held in the final position, the function miscalculates the amount to be withdrawn from that specific position. This discrepancy causes the helper function to return an incorrect, inflated withdrawal amount. Users relying on this output to execute their withdrawals may inadvertently trigger transactions that move significantly more funds than intended, leading to the unintended depletion of their liquidity.
Olas: Wrong invocation of Whirpools's updateFeesAndRewards will cause it to always revert
The Olas liquidity lockbox contract contains a logic error that prevents users from fully withdrawing their deposits and closing their positions. When a user attempts to remove all remaining liquidity from a position, the contract incorrectly invokes the `updateFeesAndRewards` function on the Orca Whirlpool pool before finalizing the withdrawal. Because the Orca Whirlpool program explicitly reverts if an update is requested for a position with zero liquidity, this process fails, rendering the user's funds effectively locked within the contract.
Olas: Missing slippage protection in `liquidity_lockbox::withdraw`
The `liquidity_lockbox` contract fails to implement slippage protection when withdrawing liquidity from Orca whirlpools. By hardcoding the minimum required token outputs to zero, the contract ignores potential market fluctuations and MEV activity during the transaction. This oversight allows users to receive significantly fewer tokens than anticipated, as the system does not revert transactions that fall below fair value expectations.
All reports in this group
- Olas: Griefing attack on `liquidity_lockbox` withdrawals due to lack of minimum depositLogic error$0
- Olas: Withdrawals can be frozen by creating null depositsInteger overflow/underflow$0
- Olas: LP rewards in `liquidity_lockbox` can be arbitragedFlash loan attack$0
- Olas: Permanent DOS in `liquidity_lockbox` for under $10Logic error$0