solana-security

---

name: solana-security description: Audit Solana programs (Anchor or native Rust) for security vulnerabilities. Use when reviewing smart contract security, finding exploits, analyzing attack vectors, performing security assessments, or when explicitly asked to audit, review security, check for bugs, or find vulnerabilities in Solana programs. metadata: version: "0.6.1"

---

Solana Security Auditing

Systematic security review framework for Solana programs, supporting both Anchor and native Rust implementations.

Review Process

Follow this systematic 5-step process for comprehensive security audits:

Step 1: Initial Assessment

Understand the program's context and structure:

Framework: Anchor vs Native Rust (check for use anchor_lang::prelude::*)

Anchor version: Check Cargo.toml for compatibility and known issues

Dependencies: Oracles (Pyth, Switchboard), external programs, token programs

Program structure: Count instructions, identify account types, analyze state management

Complexity: Lines of code, instruction count, PDA patterns

Purpose: DeFi, NFT, governance, gaming, etc.

Step 2: Systematic Security Review

For each instruction, perform security checks in this order:

1. Account Validation - Verify signer, owner, writable, and initialization checks 2. Arithmetic Safety - Check all math operations use checked_* methods 3. PDA Security - Validate canonical bumps and seed uniqueness 4. CPI Security - Ensure cross-program invocations validate target programs 5. Oracle/External Data - Verify price staleness and oracle status checks

→ See references/security-checklists.md for detailed checklists

Step 3: Vulnerability Pattern Detection

Scan for common vulnerability patterns:

Type cosplay attacks

Account reloading issues

Improper account closing

Missing lamports checks

PDA substitution attacks

Arbitrary CPI vulnerabilities

Missing ownership validation

Integer overflow/underflow

→ See references/vulnerability-patterns.md for code examples and exploit scenarios

Step 4: Architecture and Testing Review

Evaluate overall design quality:

PDA design patterns and collision prevention

Account space allocation and rent exemption

Error handling approach and coverage

Event emission for critical state changes

Compute budget optimization

Test coverage (unit, integration, fuzz)

Upgrade strategy and authority management

Step 5: Generate Security Report

Provide findings using this structure:

Severity Levels:

🔴 Critical: Funds can be stolen/lost, protocol completely broken

🟠 High: Protocol can be disrupted, partial fund loss possible

🟡 Medium: Suboptimal behavior, edge cases, griefing attacks

🔵 Low: Code quality, gas optimization, best practices

💡 Informational: Recommendations, improvements, documentation

Finding Format:

## 🔴 [CRITICAL] Title
Location: programs/vault/src/lib.rs:45-52
Issue:
Brief description of the vulnerability
Vulnerable Code:

rust // Show the problematic code

Exploit Scenario:
Step-by-step explanation of how this can be exploited
Recommendation:

rust // Show the secure alternative

References:
[Link to relevant documentation or similar exploits]

Report Summary:

Total findings by severity

Critical issues first (prioritize by risk)

Quick wins (easy fixes with high impact)

Recommendations for testing improvements

Quick Reference

Essential Checks (Every Instruction)

Anchor:

// ✅ Account validation with constraints
#[derive(Accounts)]
pub struct SecureInstruction<'info> {
    #[account(
        mut,
        has_one = authority,  // Relationship check
        seeds = [b"vault", user.key().as_ref()],
        bump,  // Canonical bump
    )]
    pub vault: Account<'info, Vault>,
    pub authority: Signer<'info>,  // Signer required
    pub token_program: Program<'info, Token>,  // Program validation
}
// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ErrorCode::Overflow)?;

Native Rust:

// ✅ Manual account validation
if !authority.is_signer {
    return Err(ProgramError::MissingRequiredSignature);
}
if vault.owner != program_id {
    return Err(ProgramError::IllegalOwner);
}
// ✅ Checked arithmetic
let total = balance.checked_add(amount)
    .ok_or(ProgramError::ArithmeticOverflow)?;

Critical Anti-Patterns

❌ Never Do:

Use saturating_* arithmetic methods (hide errors)

Use unwrap() or expect() in production code

Use init_if_needed without additional checks

Skip signer validation ("they wouldn't call this...")

Use unchecked arithmetic operations

Allow arbitrary CPI targets

Forget to reload accounts after mutations

✅ Always Do:

Use checked_* arithmetic (checked_add, checked_sub, etc.)

Use ok_or(error)? for Option unwrapping

Use explicit init with proper validation

Require Signer<'info> or is_signer checks

Use Program<'info, T> for CPI program validation

Reload accounts after external calls that mutate state

Validate account ownership, discriminators, and relationships

Framework-Specific Patterns

Anchor Security Patterns

→ See references/anchor-security.md for:

Account constraint best practices

Common Anchor-specific vulnerabilities

Secure CPI patterns with CpiContext

Event emission and monitoring

Custom error handling

Native Rust Security Patterns

→ See references/native-security.md for:

Manual account validation patterns

Secure PDA derivation and signing

Low-level CPI security

Account discriminator patterns

Rent exemption validation

Modern Practices (2025)

Use Anchor 0.30+ for latest security features

Implement Token-2022 with proper extension handling

Use InitSpace derive for automatic space calculation

Emit events for all critical state changes

Write fuzz tests with Trident framework

Document invariants in code comments

Follow progressive roadmap: Dev → Audit → Testnet → Audit → Mainnet

Security Fundamentals

→ See references/security-fundamentals.md for:

Security mindset and threat modeling

Core validation patterns (signers, owners, mutability)

Input validation best practices

State management security

Arithmetic safety

Re-entrancy considerations

Common Vulnerabilities

→ See references/vulnerability-patterns.md for:

Missing signer validation

Integer overflow/underflow

PDA substitution attacks

Account confusion

Arbitrary CPI

Type cosplay

Improper account closing

Precision loss in calculations

Each vulnerability includes:

❌ Vulnerable code example

💥 Exploit scenario

✅ Secure alternative

📚 References

Security Checklists

→ See references/security-checklists.md for:

Account validation checklist

Arithmetic safety checklist

PDA and account security checklist

CPI security checklist

Oracle and external data checklist

Token integration checklist

Known Issues and Caveats

→ See references/caveats.md for:

Solana-specific quirks and gotchas

Anchor framework limitations

Testing blind spots

Common misconceptions

Version-specific issues

Security Resources

→ See references/resources.md for:

Official security documentation

Security courses and tutorials

Vulnerability databases

Audit report examples

Security tools (Trident, fuzzers)

Security firms and auditors

Key Questions for Every Audit

Always verify these critical security properties:

1. Can an attacker substitute accounts? - PDA validation, program ID checks, has_one constraints

2. Can arithmetic overflow or underflow? - All math uses checked operations, division by zero protected

3. Are all accounts properly validated? - Owner, signer, writable, initialized checks present

4. Can the program be drained? - Authorization checks, reentrancy protection, account confusion prevention

5. What happens in edge cases? - Zero amounts, max values, closed accounts, expired data

6. Are external dependencies safe? - Oracle validation (staleness, status), CPI targets verified, token program checks

Audit Workflow

Before Starting

1. Understand the protocol purpose and mechanics 2. Review documentation and specifications 3. Set up local development environment 4. Run existing tests and check coverage

During Audit

1. Follow the 5-step review process systematically 2. Document findings with severity and remediation 3. Create proof-of-concept exploits for critical issues 4. Test fixes and verify they work

After Audit

1. Present findings clearly prioritized by severity 2. Provide actionable remediation steps 3. Re-audit after fixes are implemented 4. Document lessons learned for the protocol

Testing for Security

Beyond code review, validate security through testing:

Unit tests: Test each instruction's edge cases

Integration tests: Test cross-instruction interactions

Fuzz testing: Use Trident to discover unexpected behaviors

Exploit scenarios: Write POCs for found vulnerabilities

Upgrade testing: Verify migration paths are secure

Core Principle

In Solana's account model, attackers can pass arbitrary accounts to any instruction.

Security requires explicitly validating:

✅ Every account's ownership

✅ Every account's type (discriminator)

✅ Every account's relationships

✅ Every account's state

✅ Every signer requirement

✅ Every arithmetic operation

✅ Every external call

There are no implicit guarantees. Validate everything, trust nothing.