vulnhunter-solana

vulnhunter-solana

Manual vulnerability pattern review for Solana Rust programs. Use this during solana-audit-flow. There is no Solana static-analysis step — Slither has zero Solana detectors (slither --list-detectors → 104, none for Solana), so any "slither Solana scan" is a fabricated capability. Manual pattern matching is the primary coverage on Solana; the automated Solana tooling is dynamic (anchor build warnings, litesvm/trident fuzzing), not static taint analysis.

High-priority vuln patterns

1. Missing owner / program-id check (CRITICAL) Every account deserialized from instruction accounts must have its owner validated against the expected program ID. Pattern: if account.owner != &expected_program_id { return Err(...) }. Anchor's #[account] constraint handles this — but bare AccountInfo usage does not. Grep for AccountInfo without adjacent owner check.

2. Missing signer check (HIGH) Privileged instructions must require is_signer on the authority account. Pattern: if !authority.is_signer { return Err(ErrorCode::Unauthorized.into()) }. Anchor's Signer<'info> type enforces this — but AccountInfo with manual check can omit it. Grep for privileged state mutations without is_signer guard.

3. Account discriminator bypass (HIGH) Anchor programs use 8-byte discriminators at the start of account data to prevent type confusion. An attacker can pass a different account type that happens to deserialize without error if the discriminator is not validated. Verify try_deserialize is used (not try_deserialize_unchecked) for sensitive account types. Also check: can two different account types be interchanged via a crafted buffer?

4. CPI signer / privilege escalation (CRITICAL) When making CPIs that require signing, the invoke_signed call must pass the correct signer_seeds. A bug where the caller-controlled account address matches a PDA derivation can allow privilege escalation. Pattern: verify invoke_signed uses program-controlled seeds, not caller-provided seeds, for authority PDAs.