TL;DR
Roughly $500M of Solana's largest program-level losses trace back to seven recurring vulnerability classes: Wormhole ($320M), Mango Markets ($114M), Cashio ($52M), Crema Finance ($8.8M), Nirvana ($3.5M). None of them is a Rust memory bug. They are account-model failures: programs that trusted an account, a sysvar, a price, or a signer they never validated.
Memory safety is the property Rust gives you for free. Account safety is the property you have to build, and the one a Solana security audit exists to verify.
Why do Solana exploits look different from Ethereum exploits?
On the EVM, a contract owns its storage. On Solana, programs are stateless: every piece of state lives in an account, and any account can be passed to any instruction by anyone. The program's first job, before any business logic, is to prove that each account is what the caller claims it is: the right owner, the right type, the right derivation, actually initialized, actually signed.
Every check the runtime doesn't force is a check someone eventually forgets. That's why Solana's exploit history isn't a string of reentrancy and integer overflow stories. It's forged accounts, spoofed sysvars, and unchecked invocations.
| Exploit | Year | Loss | Class |
|---|---|---|---|
| Wormhole | 2022 | $320M | Sysvar spoofing: forged instructions sysvar bypassed signature verification |
| Mango Markets | 2022 | $114M | Oracle manipulation via concentrated trading in thin liquidity |
| Cashio | 2022 | $52M | Missing account validation: forged accounts with no root of trust |
| Crema Finance | 2022 | $8.8M | Forged price tick account reported fake liquidity prices |
| Nirvana Finance | 2022 | $3.5M | Flash-loan manipulation of a bonding-curve price |
| Drift Protocol | 2026 | $270M+ | Not a program bug: durable-nonce signing workflow abuse |
The Drift line matters: by 2026, attackers had moved up the stack. More on that below.
The seven vulnerability classes
1. Missing account validation
The defining Solana bug. A program reads an account's data without verifying its owner, type, or initialization status, so an attacker substitutes an account they control. Cashio's $52M exploit chained forged accounts with no root of trust all the way to an unlimited mint: the collateral-backing check trusted a chain of accounts that nobody anchored to a known authority.
What an audit checks: every account in every instruction traced to a validation (owner checks, discriminator and type checks, init state), and a documented reason wherever a check is intentionally absent.
2. Sysvar and account spoofing
Sysvars (clock, rent, instructions) look like trusted system data, but if a program reads them from an unvalidated account, they're attacker input. Wormhole's $320M exploit used a deprecated function that let a forged instructions sysvar through, bypassing guardian signature verification entirely.
What an audit checks: sysvars loaded via the runtime's checked APIs, never from caller-supplied accounts, with no deprecated loading paths anywhere in the dependency tree.
3. CPI confusion and unchecked program IDs
Cross-Program Invocations to an address the caller supplies are an invitation to invoke attacker code that mimics the expected interface. Signature and authority context can be spoofed by the fake callee.
What an audit checks: every CPI target pinned to a known program ID. No instruction accepts "the token program" as an argument without verifying it is the token program.
4. PDA seed collisions and non-canonical bumps
Program Derived Addresses are only as unique as their seeds. Weak or predictable seeds let attackers derive colliding addresses. Accepting non-canonical bump seeds lets spoofed PDAs pass validation that looks correct.
What an audit checks: seed schemas for collision resistance across the whole program (not per-instruction), and canonical-bump enforcement on every derivation.
5. Signer authorization gaps
Privileged instructions (admin functions, withdrawals, state mutations) that never verify the authority actually signed. The account model makes this easy to get wrong: holding a reference to the admin account is not the same as the admin having signed this transaction.
What an audit checks: a signer-requirement matrix for every instruction, verified against the implementation, with special attention to instructions that compose via CPI.
6. Unchecked arithmetic in release mode
Rust panics on overflow in debug builds and silently wraps in release builds unless you opt into checked math. Programs that "passed all tests" ship exploitable arithmetic because the tests ran with debug assertions on.
What an audit checks: checked or saturating math on every value path that touches token amounts, share prices, or collateral ratios. overflow-checks = true is a backstop, not a strategy.
7. Oracle and price manipulation
Not unique to Solana, but Solana's 2022 cohort is a casebook: Mango ($114M) via concentrated trading against a thin oracle market, Crema ($8.8M) via a forged price tick account, Nirvana ($3.5M) via flash-loan pressure on a bonding curve. In each case the program believed a price that one actor could move or fabricate within a single slot.
What an audit checks: manipulation cost of every price source in dollar terms at current liquidity, staleness and confidence handling, and what happens to liquidations and mints when the price is wrong anyway.
Doesn't Anchor fix all this?
Anchor's constraint system eliminates a lot of boilerplate validation, and programs written with idiomatic Anchor avoid the cheapest versions of classes 1, 4, and 5. It does not eliminate business-logic bugs, CPI trust decisions, oracle design, or arithmetic policy. UncheckedAccount escape hatches reintroduce everything the constraints removed, one annotation at a time.
Anchor moves the audit's starting line. It doesn't move the finish line.
What changed by 2026?
The program-level classes above caused the 2022 wave. The biggest Solana loss since is different in kind: Drift Protocol's $270M exploit had no program bug at all. Attackers abused durable nonces to pre-sign malicious multisig transactions nine days before execution, then walked them past a 2-of-5 signer set. The code was fine. The signing workflow wasn't.
That's the pattern across DeFi, not just Solana: as audit-firm effectiveness data across $10.77B in hacks shows, attackers increasingly route around audited code into configuration, key custody, and operational workflows. A Solana security program in 2026 needs both layers: program-level review for the seven classes above, and operational review of signing, upgrade authority, and monitoring.
Pre-launch checklist for Solana teams
- Map every instruction's accounts and write down the validation each one requires, then verify the code matches the map.
- Pin every CPI to a known program ID. No exceptions for "well-known" programs.
- Enforce canonical bumps on every PDA derivation.
- Turn on
overflow-checksin release profiles, then still use checked math on value paths. - Price every oracle's manipulation cost in dollars at current liquidity.
- Treat durable-nonce transactions in your multisig workflow as high-risk by default.
- Get the program audited before mainnet, and re-audited after material changes, because the report is scoped to one commit.
Where SigIntZero fits
Our auditors are Rust-native and Solana is our primary focus. A Solana security audit reviews your programs against exactly these classes (account validation, CPI safety, PDA correctness, signer authorization, arithmetic policy, and oracle design) as part of a Rust smart contract audit methodology built for the account model rather than adapted from EVM checklists.
Before the audit, Sentinel runs automated Solana-specific analysis from $100 per scan. After deployment, Tripwire watches the operational surface the 2026 attacks target: authority transfers, upgrade calls, signer changes, and anomalous fund movements, with alerts in seconds.
If you're shipping a Solana program that will custody real value, talk to us before mainnet.
Frequently Asked Questions
Is Rust safer than Solidity for smart contracts?
Rust eliminates memory-corruption bugs, but Solana's exploit history shows the dominant risks live in the account model: validation, CPI trust, PDA derivation, and signer checks. Different language. Different vulnerability classes, not fewer.
What is the most common Solana vulnerability?
Missing account validation: programs that read accounts without verifying owner, type, or initialization. It's the class behind Cashio's $52M loss and the first thing reviewed in any serious Solana audit.
Does using Anchor make an audit unnecessary?
No. Anchor's constraints remove boilerplate validation errors but not business-logic flaws, CPI trust decisions, oracle design, or the escape hatches (UncheckedAccount) that reintroduce raw risk. Audited Anchor programs still produce critical findings.
How much does a Solana smart contract audit cost?
Priced by scope: review time and auditor count, not lines alone. Rust work often carries a premium because the specialist pool is smaller. Fixed quote after a free scoping review; see pricing for current ranges.
Sources
- coral-xyz/sealevel-attacks, the canonical catalog of Solana program attack patterns
- Neodyme: Solana common pitfalls, early documentation of the account-validation classes
- Drift Protocol $270M exploit breakdown, the 2026 shift from program bugs to signing workflows
