0x-shashi/skills/solana-scanner

Solana Scanner Skill

Purpose

Analyze Solana programs (Rust/Anchor) for security vulnerabilities specific to the Solana runtime model. Solana's account-based execution model, where programs are stateless and all state is passed via accounts, creates a fundamentally different attack surface from EVM chains.

Core Principle

An attacker controls every account, argument, ordering, and CPI call-graph passed to your program. Your on-chain code must prove each input is legitimate before touching state or funds.

Solana Security Model

| Property | Solana | EVM | |----------|--------|-----| | Execution model | Programs receive accounts as input | Contracts own their storage | | State ownership | Account owner (program ID) controls data | Contract controls its own storage | | Caller identity | Signer flag on accounts | msg.sender | | Cross-program calls | CPI — accounts passed through | Internal calls share storage | | Math safety | Overflow wraps in release mode | Solidity 0.8+ reverts on overflow | | Account validation | Manual (native) or declarative (Anchor) | Automatic via msg.sender | | Upgrades | Program authority can upgrade any time | Proxy patterns required | | Rent | Accounts must maintain minimum SOL balance | No rent (storage is permanent) |

Detection Capabilities

Critical — Direct Fund Loss

| Vulnerability | Description | Detection Signal | |---------------|-------------|-----------------| | Missing signer check | Privileged instruction lacks signer validation | AccountInfo without is_signer check | | Missing owner check | Program accepts accounts owned by other programs | No owner == program_id validation | | Arbitrary CPI | Cross-program invocation to user-controlled program ID | invoke() with unchecked program_id | | PDA seed manipulation | PDA derived with controllable seeds | Seeds include user-controlled data without validation | | Account data overwrite | Writing data to wrong account | Missing discriminator / account type check |

High — Significant Impact

| Vulnerability | Description | Detection Signal | |---------------|-------------|-----------------| | Integer overflow (release) | Wrapping arithmetic in release builds | Math ops without checked_* or Anchor require! | | Account closing revival | Closed account can be revived in same tx | Close without zeroing data + relying on zero lamports | | Duplicate account injection | Same account passed for two different parameters | No uniqueness check between accounts | | Type confusion | Account deserialized as wrong type | Missing discriminator validation | | CPI privilege escalation | CPI inherits signer privileges incorrectly | invoke_signed() with wrong seeds |

Medium — Conditional Impact

| Vulnerability | Description | Detection Signal | |---------------|-------------|-----------------| | PDA bump seed guessing | Not storing/reusing canonical bump | find_program_address in instruction logic | | Missing rent exemption | Account may be garbage collected | No rent-exempt check after creation | | Unchecked account size | Account realloc without bounds | realloc() without size validation | | Clock dependency | Using Clock::get() for security-sensitive logic | Validator can influence timestamp slightly | | Token account validation | SPL Token account not validated for mint/owner | Missing token::mint or token::authority check |

Key Audit Patterns

Vulnerability Categories with Prevention Code

Each category shows the risk, an attack example, and prevention for both Anchor and Pinocchio/native Rust.

1. Missing Owner Checks

Risk: Attacker substitutes a fake account owned by their own program with crafted data.

// Anchor Prevention — Account<'info, T> auto-checks owner
#[account]
pub struct Vault { pub authority: Pubkey, pub balance: u64 }

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

// Pinocchio Prevention — explicit owner check
assert!(vault.is_owned_by(&crate::ID), ProgramError::IllegalOwner);

2. Missing Signer Checks

Risk: Anyone can call privileged instructions (withdraw, admin config).

// Anchor: Signer<'info> enforces is_signer automatically
pub authority: Signer<'info>,

// Pinocchio: manual check
assert!(authority.is_signer(), ProgramError::MissingRequiredSignature);

3. Arbitrary CPI

Risk: Attacker passes a malicious program ID, redirecting CPI to their program.

// Anchor Prevention — Program<'info, T> validates executable + ID
pub token_program: Program<'info, Token>,

// Pinocchio Prevention — compare key against known constant
assert_eq!(token_program.key(), &spl_token::ID);

4. Reinitialization

Risk: Attacker re-calls initialize to overwrite authority/settings.

// Anchor: init constraint creates + sets discriminator in one atomic step
#[account(init, payer = user, space = 8 + Vault::INIT_SPACE)]
pub vault: Account<'info, Vault>,
// ⚠️ Avoid init_if_needed — lets attacker front-run with bad data

// Pinocchio: check discriminator before writing
let data = vault.try_borrow_data()?;
assert_eq!(data[0..8], [0u8; 8], "already initialized");

5. PDA Sharing

Risk: Multiple users share one PDA → state confusion, fund theft.

// ❌ Bad: seeds only use pool-level data
#[account(seeds = [b"pool", pool.mint.as_ref()], bump)]

// ✅ Good: include user-specific identifier
#[account(seeds = [b"position", pool.key().as_ref(), user.key().as_ref()], bump)]

6. Type Cosplay

Risk: Attacker passes account of type A where type B is expected (same size).

// Anchor auto-adds 8-byte discriminator to all #[account] types,
// and Account<'info, T> validates it on deserialization.

// Pinocchio: first 8 bytes must be a unique discriminator per type
let disc = &data[0..8];
assert_eq!(disc, VAULT_DISCRIMINATOR, "wrong account type");

7. Duplicate Mutable Accounts

Risk: Same account passed as both source and destination → double-counting.

// Both frameworks — explicit key comparison
require!(source.key() != destination.key(), ErrorCode::DuplicateAccounts);

8. Account Revival (Closing)

Risk: Closed account (0 lamports) data remains in tx — later instruction reads stale state.

// Anchor: close transfers lamports + zero discriminator
#[account(mut, close = destination)]
pub vault: Account<'info, Vault>,

// Pinocchio: manually zero + transfer + realloc
data[0] = 0xFF; // poison discriminator
**vault.try_borrow_mut_lamports()? = 0;
**destination.try_borrow_mut_lamports()? += lamports;
vault.realloc(0, false)?;

9. Data Matching

Risk: Token account's mint or authority doesn't match expected values.

// Anchor: has_one validates field matches account key
#[account(mut, has_one = authority, has_one = mint)]
pub token_acct: Account<'info, TokenAccount>,

// Pinocchio: manual comparison
assert_eq!(token_acct.authority, expected_authority.key());

Account Validation Matrix

Every instruction must validate EVERY account it accesses. Use this matrix:

| Check | Native Solana | Anchor | |-------|--------------|--------| | Is signer? | account.is_signer | Signer<'info> | | Is writable? | account.is_writable | #[account(mut)] | | Correct owner? | account.owner == &program_id | Account<'info, T> (automatic) | | Correct PDA? | Pubkey::find_program_address() | #[account(seeds = [...], bump)] | | Correct data type? | Check discriminator manually | Account<'info, T> (automatic) | | Belongs to user? | Manual field comparison | #[account(has_one = owner)] | | Not closed? | Check lamports > 0 and data | Account<'info, T> (checks discriminator) | | Unique? | Compare pubkeys between params | Manual (Anchor doesn't auto-check) |

Solana-Specific Attack Vectors

1. Account Confusion Attack: Passing a token account where a mint account is expected (or vice versa)
2. Reinitialization Attack: Calling initialize on already-initialized account
3. Closing Account Revival: Closing an account (zero lamports) but data remains readable in same tx
4. CPI Re-signer Attack: Exploiting that CPI can sign with PDA seeds the caller controls
5. Remaining Accounts Abuse: Exploiting unchecked accounts in ctx.remaining_accounts
6. Flashback Attack: Solana transactions can include multiple instructions — attacker can create and exploit account state in same tx

Program-Side Security Checklist

Account Validation (7 checks)

• [ ] Every account has an owner check (native) or uses Account<'info, T> (Anchor)
• [ ] Every privileged account has a signer check
• [ ] PDAs are derived with sufficient unique seeds (no PDA sharing)
• [ ] All accounts have discriminator validation (type cosplay prevention)
• [ ] Semantically distinct accounts are compared for uniqueness
• [ ] has_one / manual field comparison for data matching (mint, authority)
• [ ] Accounts in remaining_accounts are validated before use

CPI Safety (3 checks)

• [ ] CPI target is a known program (Program<'info, T> or key comparison)
• [ ] invoke_signed seeds are deterministic and cannot be replayed
• [ ] CPI return data is validated, not blindly trusted

Arithmetic (3 checks)

• [ ] All math uses checked_* operations or overflow-checks = true in Cargo.toml
• [ ] Token amounts validated against actual balances before transfer
• [ ] Fee/reward calculations handle rounding and zero-value edge cases

State Lifecycle (4 checks)

• [ ] init is used instead of init_if_needed (prevents front-running)
• [ ] Closed accounts are zeroed + poisoned (discriminator = 0xFF)
• [ ] Upgrade authority is verified or program is immutable in production
• [ ] Account realloc operations check size bounds

Client-Side Security Checklist

• [ ] Correct cluster (mainnet vs devnet) — program IDs differ
• [ ] Transactions are simulated before sending to catch errors early
• [ ] getLatestBlockhash uses confirmed or finalized commitment
• [ ] Transaction confirmation waits for sufficient commitment level
• [ ] Token-2022 extensions (transfer hooks, transfer fees) are handled
• [ ] Lookup tables / versioned transactions are used for large account sets
• [ ] Priority fees are set appropriately for congested network conditions

Build & IDL Integrity Checklist

Supply-chain and deployment verification — catches mismatches between audited source and deployed program.

• [ ] On-chain program matches audited source — verify with solana program dump + local rebuild
• [ ] IDL matches on-chain behavior — generated IDL (Anchor/Codama) reflects actual instruction layouts
• [ ] No hand-written Borsh layouts for programs the team owns — use IDL/codegen pipeline (hand-written layouts risk serialization mismatches → type confusion)
• [ ] No hand-written IDLs — generate from source via anchor build or Shank macros
• [ ] Codegen outputs checked into git for deterministic builds, or generated in CI with pinned versions
• [ ] Anchor version pinned in Anchor.toml — different Anchor versions produce different discriminators
• [ ] Solana CLI + Anchor versions aligned across dev, CI, and audit environments
• [ ] Program upgrade authority is multisig or governance (not a single EOA) for mainnet deployments
• [ ] If upgradeable, upgrade timelock exists to allow users to exit before code changes

Security Review Questions

When reviewing a Solana program, systematically ask:

1. Can an attacker pass a fake account (wrong owner / wrong type)?
2. Can a non-authorized user trigger this instruction?
3. Can CPI be substituted to a malicious program?
4. Can initialize be called again on an existing account?
5. Are PDAs shared across users or contexts unintentionally?
6. Can the same account be passed for two different params?
7. Can a closed account be read or revived in a later instruction?
8. Do on-chain fields match expected accounts (authority, mint, owner)?

Solana Audit Procedure

Step-by-step execution flow when auditing a Solana program. Adapted from Solana Foundation's recommended operating procedure.

Step 1: Classify the Program

| Question | Why It Matters | |----------|----------------| | Anchor or native/Pinocchio? | Determines which constraint system to audit (declarative vs manual) | | What token programs are used? | SPL Token vs Token-2022 — different extension attack surfaces | | Is the program upgradeable? | If yes, audit the upgrade authority and governance process | | Does it use CPI? | Cross-program calls are the #1 privilege escalation vector | | Are there multiple instructions per tx? | Multi-instruction flows enable flashback attacks |

Step 2: Map Every Account

For each instruction, build the Account Validation Matrix (see above). Every cell must be explicitly checked in code. An empty cell is a potential vulnerability.

Step 3: Trace CPI Chains

For each invoke() / invoke_signed():

1. Is the target program ID validated? (Program<'info, T> or key comparison)
2. Are signer seeds deterministic and non-replayable?
3. Does the CPI return data get validated, or is it blindly trusted?
4. Can an attacker substitute a malicious program ID?

Step 4: Verify Arithmetic Safety

1. Check Cargo.toml for overflow-checks = true (release profile)
2. If not present, every arithmetic operation must use checked_*
3. Verify token amount calculations handle rounding and zero-value edge cases
4. Check for division before multiplication (precision loss)

Step 5: Evaluate Formal Verification (if present)

If the program includes Kani proofs or other formal verification:

1. Inventory proofs — count, classify (STRONG/WEAK/VACUOUS), categorize by domain
2. Map proofs to security claims — does the proof actually back the claim?
3. Identify what is NOT proven — CPI execution, oracle reads, and runtime behavior are never Kani-verifiable
4. Check for coupling proofs — does the verify module match the production handler?
5. Flag vacuous proofs — any proof with contradictory assume() chains is a finding
6. Report strength — "N proofs (X% STRONG) covering [categories]"

See Formal Verification for Auditors for proof classification and evaluation methodology.

Step 6: Test with PoCs

Use the testing tools to write targeted PoCs for any findings:

• LiteSVM — Fast in-process execution for exploit PoCs (seconds, not minutes)
• Mollusk — Direct program execution for CU impact analysis
• Surfpool — Integration testing against real mainnet state (Jupiter, Orca, etc.)

See Solana Testing for Auditors for setup guides.

Step 7: Deliverables

For each finding, provide:

• Vulnerability category (from the 9 categories above)
• Affected instruction(s) with account layout
• Exploit scenario — step-by-step attack using concrete accounts
• PoC code (if applicable) using LiteSVM or Mollusk
• Fix recommendation with Anchor and/or native Rust code
• Risk notes for anything touching signing, fees, CPIs, or token transfers

Workflows

| Workflow | Description | |----------|-------------| | Anchor Audit | Audit workflow for Anchor framework programs — constraint validation, CPI safety, PDA verification | | Native Audit | Audit workflow for native Solana programs — manual account deserialization, raw instruction processing |

Resources

| Resource | Description | |----------|-------------| | Account Validation | Complete guide to account validation checks: signer, owner, PDA, type, uniqueness | | Anchor Security | Anchor-specific security patterns: constraints, CPI, init_if_needed, close | | Solana Patterns | Common vulnerability patterns with code examples and fixes | | Curated Links | 50+ curated links to official docs, audit reports, security courses, tools, and firms | | Security Fundamentals | Core Solana security principles, threat model, and best practices | | Native Security | Native Solana (non-Anchor) security patterns and pitfalls | | Security Checklists | Audit and client-side checklists for Solana programs | | Caveats | Solana-specific caveats, gotchas, and edge cases for auditors | | Formal Verification | Kani proof evaluation: classification, property categories, verify module extract-and-prove pattern | | Adversarial Test Design | Attack-first test taxonomy, conservation invariant methodology, 10-category checklist |

Notable Solana Security Incidents

| Incident | Date | Root Cause | Loss | |----------|------|-----------|------| | Wormhole bridge | Feb 2022 | Missing signer verification on complete_wrapped | $326M | | Cashio stablecoin | Mar 2022 | Missing crate_collateral_tokens.mint validation | $52M | | Mango Markets | Oct 2022 | Oracle price manipulation + account borrowing | $116M | | Crema Finance | Jul 2022 | Fake tick account injection in CPI | $8.8M | | Slope wallet | Aug 2022 | Private key logging in centralized server | $4.1M | | Solend | Various | Multiple oracle and liquidation issues | Various |

Ecosystem Context

| Metric | Value | |--------|-------| | Smart contract language | Rust | | Primary framework | Anchor (>90% of new projects) | | Block time | ~400ms | | Transaction model | Multiple instructions per transaction | | Account size limit | 10MB | | Compute budget | 200,000 compute units per instruction (adjustable to 1.4M) | | Token standard | SPL Token / Token-2022 | | NFT standard | Metaplex Token Metadata |

Integration with Other Skills

| Skill | Connection | |-------|-----------| | patterns/ | Cross-reference Solana-specific patterns with Solodit database (limited but growing) | | exploit-forensics/ | Wormhole, Cashio, Mango exploits provide forensic case studies | | chain-guides/solana.md | Chain-level context for Solana validator behavior, consensus, fees | | attack-trees/ | Solana-specific attack trees (account confusion, CPI escalation) |

Error Code Reference

Common Solana program error codes encountered during audits. These appear in transaction logs and simulation failures.

Anchor Framework Errors

| Error Code | Error Name | Meaning | |------------|-----------|----------| | 0x64 (100) | InstructionMissing | Expected instruction not found in transaction | | 0x65 (101) | InstructionFallbackNotFound | No fallback handler for instruction | | 0xBB8 (3000) | ConstraintMut | Account not marked as mutable (#[account(mut)] missing) | | 0xBB9 (3001) | ConstraintHasOne | has_one constraint failed — account field doesn't match | | 0xBBA (3002) | ConstraintSigner | Account is not a signer | | 0xBBB (3003) | ConstraintRaw | Custom constraint = <expr> evaluated to false | | 0xBBC (3004) | ConstraintOwner | Account owner does not match expected program | | 0xBBF (3007) | ConstraintSeeds | PDA seeds do not derive the expected address | | 0xBC4 (3012) | ConstraintSpace | Account data space insufficient | | 0x7D0 (2000) | DeclaredProgramIdMismatch | declare_id! does not match actual program ID | | 0x7D1 (2001) | TryingToInitPayerAsProgramAccount | Payer account reused as program-owned account | | 0xBCE (3022) | AccountNotInitialized | Account data is empty / uninitialized | | 0xBC0 (3008) | ConstraintExecutable | Account is not an executable program | | 0x1770 (6000)+ | Custom errors | Application-specific errors start at 6000 |

SPL Token Program Errors

| Error Code | Error Name | Meaning | |------------|-----------|----------| | 0x0 | NotRentExempt | Account balance below rent-exempt minimum | | 0x1 | InsufficientFunds | Token balance too low for transfer | | 0x3 | InvalidMint | Token account mint does not match expected mint | | 0x4 | MintMismatch | Mint of token account does not match instruction mint | | 0x5 | OwnerMismatch | Token account owner does not match expected owner | | 0xA | AlreadyInUse | Account is already initialized | | 0xC | InvalidNumberOfProvidedSigners | Wrong number of multisig signers | | 0xD | InvalidNumberOfRequiredSigners | Invalid multisig threshold | | 0x11 | AccountFrozen | Token account is frozen — transfers blocked |

System Program / Runtime Errors

| Error Code | Error Name | Meaning | |------------|-----------|----------| | 0x0 | InsufficientFundsForRent | Account will drop below rent-exempt after operation | | 0x1 | AccountAlreadyInitialized | Cannot reinitialize existing account | | 0x3 | AccountNotFound | Referenced account does not exist | | ProgramFailedToComplete | (Runtime) | Program exceeded compute budget or panicked | | PrivilegeEscalation | (Runtime) | CPI attempted to escalate privileges | | AccountDataTooSmall | (Runtime) | Account data buffer too small for deserialization |

Troubleshooting

| Issue | Likely Cause | Solution | |-------|-------------|----------| | Scanner misses missing-signer vulnerabilities | Native program uses AccountInfo without Anchor constraints | Check all AccountInfo params for explicit is_signer / is_writable validation | | False positive on PDA seeds | Scanner flags all user-controlled seeds | Verify if seeds are bounded by program logic; canonical bump stored correctly | | Account confusion not detected | Different account types share same structure size | Check discriminator bytes; Anchor auto-adds 8-byte discriminators | | CPI privilege escalation missed | invoke_signed seeds not analyzed | Manually trace PDA seed derivation through CPI chain | | Scanner doesn't flag overflow in release mode | Release builds wrap instead of panic | Flag all non-checked_* math ops; verify overflow-checks = true in Cargo.toml | | Duplicate account injection not caught | Scanner doesn't check account uniqueness | Verify all instruction accounts are compared for uniqueness where semantically distinct |