Solana Smart Contract Security: Common Vulnerabilities Checklist

Solana programs hold real money from the moment they're deployed, and most losses come from a short list of well-known mistakes. The good news: they're preventable. This checklist covers the vulnerabilities we look for first in every security review, and how to avoid them.

Why Solana is different

On Solana, a program doesn't own its data the way an Ethereum contract does. Instead, every instruction receives a list of accounts from the caller, and it's up to the program to check that each one is what it claims to be. Most Solana vulnerabilities come down to trusting an account the program should have checked.

1. Missing signer checks

If an instruction should only run when a particular wallet approves it, the program must check that wallet signed the transaction. Otherwise anyone can pass that wallet's address and act on its behalf.

In Anchor, use the Signer type for accounts that must sign.

2. Missing owner checks

A program must confirm that each account it reads is owned by the expected program. An attacker can create an account with exactly the right data layout, owned by their own program, and pass it in place of the real one.

Anchor's Account<T> type checks ownership automatically; raw AccountInfo doesn't.

3. Account confusion

Even an account owned by your program might be the wrong one: another user's vault, a different pool, or an account of a different type with a similar layout.

• Derive important accounts as PDAs from known seeds and check them.
• Use Anchor's has_one and seeds constraints to tie accounts together.
• Use distinct account types (Anchor adds a discriminator to each) so one type can't be passed as another.

4. Arithmetic errors

Overflows, underflows and rounding mistakes are a classic way to mint value from nothing. Use checked arithmetic (checked_add, checked_mul and friends), and think about which way each division rounds: it should never round in the user's favour at the protocol's expense.

5. Unsafe cross-program invocations (CPIs)

When your program calls another, make sure it's calling the real program, not an attacker's lookalike passed in as an account. Check program IDs, and be careful passing signer privileges through to other programs.

6. Re-initialisation and closing bugs

• An initialise instruction that can run twice may let an attacker overwrite an account's owner or settings.
• An account that's closed but not properly zeroed can sometimes be revived in the same transaction.

Anchor's init and close constraints handle most of this correctly; custom code needs extra care.

7. Business-logic flaws

The hardest bugs are in your own rules: rewards that can be claimed twice, prices that can be manipulated within one transaction, or edge cases with zero or huge amounts. Write down what must always be true (for example, "total deposits equal the vault balance") and test that it holds.

8. Upgrade authority and keys

A perfect program can still be drained if the key that can upgrade it is stolen. Put the upgrade authority behind a multisig such as Squads, or make the program immutable once it's stable, and keep deployment keys off everyday machines.

How to test for these

• Unit and integration tests for every instruction, including the ones that should fail.
• Fuzzing the riskiest instructions with random inputs and account orders.
• Local test environments such as LiteSVM or Bankrun for fast, realistic tests.
• Devnet deployment with realistic scenarios before mainnet.
• An independent review for anything holding user funds.

Before you launch

If your program will hold other people's money, get a second set of eyes on it. Our Solana security review covers everything above with a written report and fix verification. Building something new? Our DeFi and program development includes testing and review from the start, and what drives the cost of a Solana dApp explains how to budget for it.