SVM Program Fuzzing Framework

Overview

The SVM fuzzing framework is a coverage-guided fuzzing engine for Solana programs. It provides instruction-aware input generation, account state fuzzing, CPI call simulation, invariant checking for Solana-specific properties, and crash detection with reproduction. The framework targets the full set of Solana vulnerability classes: missing signer checks, PDA manipulation, CPI reentrancy, account type confusion, lamport draining, arithmetic overflow, and unsafe deserialization.

The framework treats Solana’s account model as a first-class concern. Inputs are not raw byte sequences — they are complete account sets with configurable signer flags, writability flags, owner program IDs, and lamport balances. This allows the fuzzer to discover authorization vulnerabilities that only manifest when specific account configurations are presented to an instruction.

Note: The fuzzing framework is for vulnerability validation purposes only. Findings produced by fuzzing represent confirmed or likely-exploitable vulnerabilities in the analyzed program.

Attack Scenario

Solana program fuzzing discovers vulnerabilities by executing thousands of randomized instruction sequences and checking program-specific invariants after each successful execution. A typical fuzzing-driven exploit discovery follows this flow:

Instruction schema extraction: The fuzzer identifies the program’s instruction discriminators (8-byte Anchor prefixes or custom opcodes) and generates inputs with valid discriminator values.
Account set generation: For each instruction, the fuzzer generates account sets with varying signer and writable flags, account sizes, and owner program IDs — including combinations that violate expected constraints.
Execution and invariant checking: The program is executed against each generated input. After execution, invariant checkers evaluate whether the program’s state transitions violate security properties.
Violation detected: When an invariant fails — for example, authority-gated state modified without a valid signer — the triggering input is recorded as an exploit candidate.
Crash reproduction: The triggering input is replayed in isolation to confirm reproducibility and generate a proof-of-concept transaction.

For CPI scenarios, the fuzzer simulates intermediate program calls to discover reentrancy and callback-based vulnerabilities.

Exploit Mechanics

Instruction-Aware Input Generation

The input generator produces Solana-aware instruction data and account sets:

Instruction data: Generated with valid Anchor discriminators for known instruction types, with fuzzed payload bytes for parameter values (amounts, indices, seeds).
Account sets: Generated with plausible combinations of is_signer, is_writable, and owner values, including edge cases such as an authority account with is_signer = false or a PDA with the wrong program owner.
CPI call sequences: Simulated to explore vulnerabilities that only manifest during intermediate program interactions, including reentrancy via callback patterns.

// Illustrative: The fuzzer generates account sets to probe signer check coverage
// A valid transaction would have authority.is_signer = true
// The fuzzer also generates the invalid case: authority.is_signer = false

// Discovered: update_authority() succeeds with is_signer = false
// Missing signer check confirmed — program accepts unauthorized updates

Solana-Specific Invariant Checking

The framework verifies Solana-specific security properties after each successful instruction execution:

Invariant	What It Checks
Signer Required	Instructions requiring signers reject executions where the authority account has `is_signer = false`
Balance Conservation	Total lamport balance across all accounts is conserved (no creation or destruction outside expected operations)
PDA Ownership Preserved	PDA-controlled accounts are not transferred to unexpected program owners after instruction execution
Account Type Preserved	Account discriminators (8-byte Anchor type prefixes) are not corrupted during execution
Rent Exemption Maintained	Accounts remain above the rent-exempt minimum lamport balance after operations

Coverage-Guided Corpus Evolution

Like the EVM framework, the SVM fuzzer uses coverage feedback to guide corpus evolution. Inputs that exercise new program paths are retained and mutated. For Solana programs, coverage is tracked at the instruction handler level — which handler branches were taken, which constraint checks passed or failed.

CPI Simulation

Cross-Program Invocation (CPI) calls are simulated by intercepting outgoing CPI calls and injecting a malicious callback program as the callee. This simulates A → B → A reentrancy scenarios where a malicious intermediate program re-enters the victim before state is finalized.

The simulation checks whether the re-entrant call succeeds and whether it observes inconsistent state (such as a non-zeroed balance from a withdrawal that has not yet completed).

Crash Detection

The fuzzer captures all program failures for analysis:

Panic: The program panicked (assertion failure, arithmetic overflow in debug mode, index out of bounds)
Invalid instruction: Unknown instruction discriminator or malformed instruction data
Account validation failed: Anchor constraint violation (wrong owner, size mismatch, missing signer)
CPI failure: Cross-program invocation returned an error
Insufficient funds: Lamport balance too low for the requested operation

Each crash includes the triggering input — the complete instruction data and account set — for deterministic reproduction.

Remediation

Individual vulnerability findings from the fuzzer link to their corresponding detector and remediation documentation. Common fuzzer-discovered vulnerability classes in Solana programs include:

Missing Signer Check: Missing Signer Check Detector | Remediation
PDA Manipulation: Bump Seed Canonicalization Detector | Remediation
CPI Reentrancy: Arbitrary CPI Detector | Remediation
Lamport Drain: Lamport Drain Detector | Remediation
Integer Overflow: Integer Overflow Detector | Remediation