DEV Community: Viktor Andriichuk

Common Solana Program Vulnerabilities and How to Catch Them

Viktor Andriichuk — Tue, 28 Jul 2026 20:21:00 +0000

Most Solana exploits don't come from exotic cryptography or clever math. They come from a handful of well-understood mistakes that show up again and again — usually because Solana's account model puts the burden of validation on you, the program author, rather than the runtime.

If you write Solana programs in Rust or Anchor, this is the list of bugs worth internalizing. For each one below you'll find why it happens, a vulnerable example, and the fix.

Why Solana programs break differently

On Ethereum, a contract's storage is bound to the contract. On Solana, programs are stateless: all state lives in separate accounts that the caller passes in with each instruction. That design is fast and flexible, but it has a consequence that trips up almost every new Solana developer:

The runtime does not guarantee that an account is what you think it is. Anyone can pass any account into your instruction. If your program doesn't explicitly check that an account is a signer, is owned by the right program, is the right type, or was derived from the right seeds — an attacker will pass one that isn't.

Almost every vulnerability class below is a variation on that single theme: validate the accounts you were handed.

1. Missing signer checks

The most common and most expensive bug. If an account is supposed to authorize an action, it must sign the transaction. If you forget to enforce that, anyone can act as anyone.

Vulnerable
#[derive(Accounts)] pub struct Withdraw<'info> { #[account(mut)] pub vault: Account<'info, Vault>, /// CHECK: authority is not constrained — anyone can pass any account here pub authority: AccountInfo<'info>, }

Because authority is a plain AccountInfo with no signer constraint, an attacker passes the real owner's public key without their signature and drains the vault.

Fixed
#[derive(Accounts)] pub struct Withdraw<'info> { #[account(mut, has_one = authority)] pub vault: Account<'info, Vault>, pub authority: Signer<'info>, }

Signer<'info> forces the account to have signed the transaction, and has_one = authority ensures it's the specific authority stored on the vault — not just any signer.

2. Missing owner checks

Every account has an owner program. If you read data from an account without verifying who owns it, an attacker can hand you a look-alike account they created and fully control.

Anchor's Account<'info, T> checks the owner and the 8-byte discriminator automatically. The bug appears when you drop down to raw AccountInfo or UncheckedAccount and deserialize manually.

Vulnerable
// Manually deserializing without checking the owner let vault = Vault::try_from_slice(&account.data.borrow())?;

Fixed — let Anchor enforce it
#[account(owner = crate::ID)] pub vault: Account<'info, Vault>,

If you must use AccountInfo, check account.owner == &crate::ID yourself before trusting a single byte.

3. Account type confusion ("type cosplay")

Two account types with the same memory layout can be swapped for each other if you don't distinguish them. Anchor prevents this with an 8-byte discriminator prepended to every account — but only if you use typed Account. Deserialize raw, and a UserConfig can masquerade as an AdminConfig.

Fix: always use typed Anchor accounts (Account<'info, T>), which verify the discriminator, instead of decoding AccountInfo data by hand.

4. PDA seed and bump mistakes

Program Derived Addresses (PDAs) are deterministic accounts your program controls. Two things go wrong:

Seeds not validated. If you accept a PDA without re-deriving it from the expected seeds, an attacker passes a different PDA they can influence.
Non-canonical bump. find_program_address returns the canonical bump. If you store a bump and don't validate against the canonical one, an attacker may derive a valid-but-different address with another bump.

Fixed with Anchor constraints
#[account( seeds = [b"vault", user.key().as_ref()], bump = vault.bump, )] pub vault: Account<'info, Vault>,

Anchor re-derives the address from the seeds and checks the stored canonical bump for you. Store the canonical bump at init time and always validate against it.

5. Unchecked / arbitrary CPIs

When your program calls another via a Cross-Program Invocation, you must verify which program you're calling. If the target program is just an account passed in without a check, an attacker substitutes a malicious program that does whatever they want with the accounts you forwarded.

Vulnerable
// The program being invoked is whatever was passed in — never verified invoke(&ix, &[account_a, account_b, some_program])?;

Fixed: pin the program to a known ID (Anchor's typed CPI does this):

Fixed
require_keys_eq!(token_program.key(), anchor_spl::token::ID);

6. Integer overflow and underflow

This one is Rust-specific and catches people coming from other languages. Solana programs compile in release mode, where arithmetic overflow silently wraps instead of panicking. balance - amount can underflow to a huge number; reward * multiplier can wrap to a small one.

Vulnerable
vault.balance = vault.balance - amount; // underflows silently in release mode

Fixed
vault.balance = vault.balance .checked_sub(amount) .ok_or(ErrorCode::MathOverflow)?;

Use checked_* (or saturating_* where appropriate) for every arithmetic operation on values that matter. You can also set overflow-checks = true in your Cargo.toml profile, but explicit checked math is clearer and lets you return a proper error.

7. Duplicate mutable accounts

If an instruction takes two accounts of the same type and mutates both, an attacker can pass the same account twice. Logic that assumes they're distinct (e.g. transferring between two vaults) breaks in the attacker's favor.

Fix
#[account(constraint = vault_a.key() != vault_b.key())]

8. Account reinitialization and revival

Closing an account and reopening it, or reinitializing an already-initialized account, can reset state an attacker wants reset. Use Anchor's init (which fails if the account already exists) rather than init_if_needed unless you fully understand the implications, and use the close constraint to close accounts safely rather than zeroing lamports by hand.

How to catch these before you deploy

The pattern across all eight is the same: your program must validate every account it's given. Three habits prevent most of them:

Prefer Anchor's typed accounts and constraints (Signer, Account, has_one, seeds, bump, owner). They turn most of the checks above into declarative one-liners the framework enforces for you.
Use checked arithmetic everywhere on security-relevant values.
Review every AccountInfo / UncheckedAccount / /// CHECK: in your codebase — each one is a place where you've opted out of Anchor's automatic safety and taken the validation burden on yourself.

Manual review catches a lot, but it's slow and it misses things — especially the boring ones, which are exactly the expensive ones. That's the gap VaultLint is built for: an AI security linter that reads Rust and Anchor programs the way an auditor would and flags missing signer checks, PDA mistakes, unsafe CPIs, and overflow before you ship — so a full audit can focus on the hard stuff. It complements a manual audit; it doesn't replace one.

Ship fewer bugs. Catch the common, drainable mistakes in the PR, not on the first mainnet block.

How to Audit an Anchor Program: A Practical Checklist

Viktor Andriichuk — Sun, 26 Jul 2026 18:33:00 +0000

Auditing a Solana program isn't about reading every line top to bottom and hoping something jumps out. It's about knowing the small set of places where Anchor programs actually go wrong and checking each one deliberately. This guide walks through that process in the order an experienced reviewer would follow, and ends with a checklist you can paste into your review notes.

Anchor does a lot of validation for you — but only when you use its typed accounts and constraints. Most Anchor vulnerabilities are places where the author quietly opted out of that protection. So a large part of auditing an Anchor program is finding where the safety rails were removed.

Step 1: Map the instructions and their authority

Before reading any logic, list every instruction and answer one question for each: who is allowed to call this, and how is that enforced?

For every privileged instruction (withdraw, close, update-config, mint, set-authority), find the account that authorizes it and confirm it's declared as Signer<'info> and tied to the state it acts on with has_one or an explicit constraint. If the authority is an AccountInfo or UncheckedAccount, that's your first finding.

Good: authority must sign AND must match the stored authority

#[account(mut, has_one = authority)] pub config: Account<'info, Config>, pub authority: Signer<'info>,

Step 2: Grep for the escape hatches

The fastest way to find risk in an Anchor codebase is to search for the places where automatic validation was bypassed:

AccountInfo and UncheckedAccount — no owner, type, or discriminator check.
/// CHECK: comments — every one marks an account the author told Anchor to trust blindly. Read each and decide whether the accompanying validation is actually sufficient.
init_if_needed — reinitialization risk; confirm it can't be abused to reset state.
Raw invoke / invoke_signed — manual CPIs where the target program may not be verified.
try_from_slice / manual deserialization — bypasses discriminator and owner checks.

Each hit is a place to slow down. Anchor's defaults are safe; these are where safety was turned off.

Step 3: Verify account constraints

Go through each #[derive(Accounts)] struct and confirm the constraints match the intent:

Signer checks — is every authorizing account a Signer?
has_one — does state that stores an authority/owner/mint enforce it matches the passed account?
seeds + bump — are PDAs re-derived from the correct seeds, and is the stored canonical bump validated?
owner — for any account not using typed Account, is the owner checked?
mut — are exactly the accounts that get written marked mutable, and no more?
address = ... — for programs, sysvars, and known accounts, is the expected address pinned?

Step 4: Check the CPIs

For every cross-program invocation, confirm the program being called is verified, not just passed in. Prefer Anchor's typed CPI (CpiContext with a typed program account) over raw invoke. If raw invoke is used, the target program ID must be checked explicitly:

Pin the program to a known ID

require_keys_eq!(token_program.key(), anchor_spl::token::ID);

Also check that invoke_signed uses the correct PDA seeds and that you aren't accidentally signing for an account you don't control.

Step 5: Audit the arithmetic

Solana programs run in release mode, so overflow wraps silently. Search for bare +, -, * on balances, amounts, rewards, shares, and timestamps. Each should be checked_* (returning an error on overflow) or saturating_* where wrapping to a bound is intended. Watch for as casts that can truncate (u64 as u32), and for divisions that can round in the protocol's disfavor.

Step 6: Review account lifecycle

Initialization: does init prevent re-initializing existing accounts? Is the payer and space correct?
Closing: are accounts closed with Anchor's close constraint (which zeroes data and reclaims rent safely) rather than by hand? Manual closing invites revival attacks.
Rent: are accounts that must persist rent-exempt?

Step 7: Look for duplicate-account and account-ordering assumptions

If an instruction takes two accounts of the same type and mutates both, confirm they're required to be distinct (constraint = a.key() != b.key()). If logic assumes a particular relationship between accounts (e.g. "this token account belongs to this user"), confirm that relationship is enforced with a constraint, not just assumed.

The Anchor audit checklist

Copy this into your review:

Anchor program audit checklist

[ ] Every privileged instruction has a Signer that is tied to state (has_one / constraint)
[ ] No unexplained AccountInfo / UncheckedAccount on authority accounts
[ ] Every /// CHECK: is justified and backed by real validation
[ ] PDAs use seeds + canonical bump; bump is stored and validated
[ ] Typed Account used wherever possible (owner + discriminator checked)
[ ] All CPIs verify the target program ID (typed CPI or explicit check)
[ ] invoke_signed uses correct, controlled PDA seeds
[ ] All arithmetic on values-of-record uses checked_* / saturating_*
[ ] No silent truncation in as casts
[ ] init prevents reinitialization; init_if_needed justified if present
[ ] Accounts closed via Anchor close, not manual lamport draining
[ ] Same-type mutable accounts required to be distinct
[ ] mut applied only to accounts actually written
[ ] Known programs/sysvars pinned with address = ...

Where automation fits

A human auditor is irreplaceable for logic bugs and economic design flaws. But the checklist above is mostly mechanical — exactly the kind of review that's tedious to do by hand on every PR and easy to let slip under deadline. That's where an automated pass earns its keep.

VaultLint runs this style of review automatically: it reads your Anchor and native Solana programs, flags the missing constraints, unverified CPIs, and unchecked arithmetic, and tells you the file, the line, why it's dangerous, and how to fix it — in CI, on every PR. It's a linter, not a replacement for a full audit: it clears out the common, expensive mistakes early so your paid audit can spend its hours on the hard, protocol-specific stuff.