plamentsv / account-validation

ACCOUNT_VALIDATION Skill

Trigger Pattern: Always required for Solana audits
Inject Into: Breadth agents, depth agents
Finding prefix: [AV-N]
Rules referenced: S1, S6, S7, S8, R4

For every instruction handler in the Solana program:

1. Account Type Inventory

For EACH instruction, list every account with expected constraints:

Anchor auto-checks: Anchor's Account<T> validates owner + discriminator automatically. UncheckedAccount / AccountInfo do NOT - manual validation required.

2. Owner Check Audit

For each AccountInfo or UncheckedAccount usage:

Critical pattern: Any AccountInfo deserialized without prior owner check → arbitrary data injection.
Anchor pattern: #[account(owner = expected_program)] or manual require!(account.owner == &expected_id).

3. Discriminator Check

For all accounts deserialized from raw data:

Attack: Pass an account of Type B where Type A is expected - different data layout, fields interpreted incorrectly.
Safe: Anchor's Account<T> checks the 8-byte discriminator. Manual programs must check explicitly.

Anchor IDL buffer amplification: If the program uses Anchor with the default IDL feature enabled (check Cargo.toml for idl-build feature or absence of no-idl — enabled by default), IdlCreateBuffer is a permissionless instruction that lets ANYONE create program-owned accounts with nearly arbitrary data at arbitrary lengths. This means a missing discriminator check is exploitable even when no other account type in the program has a suitable layout for cosplay — the attacker crafts one via IdlCreateBuffer. When flagging a discriminator bypass: if IDL feature is enabled, severity is NOT mitigated by "no suitable account type exists for substitution."

4. Data Matching (Cross-Account References)

For each cross-account reference (has_one, constraint, seeds):

Pattern: Ensure that when Account A references Account B (e.g., vault.mint == mint.key()), the relationship is enforced on-chain.
Attack: Substitute a different mint account that the vault doesn't actually belong to.

5. Remaining Accounts Audit

For each use of ctx.remaining_accounts:

Critical: remaining_accounts bypass Anchor's automatic validation. Every field must be checked manually.
Attack: Inject attacker-controlled accounts via remaining_accounts to redirect funds or corrupt state.

6. Duplicate Account Detection

For each instruction with 2+ mutable accounts:

Attack (S7): Pass the same account as both from and to in a transfer → potential balance inflation.
Defense: require!(account_a.key() != account_b.key()) or Anchor constraint.

7. Sysvar Validation

For each sysvar account passed as input:

Safe pattern: Use Sysvar::from_account_info() or _checked variants.
Unsafe pattern: Raw deserialization of sysvar data from unchecked AccountInfo.

8. Trust Chain Analysis

For each account validation chain, trace to its root:

Pattern: Validation chain must root in a known-good value. If chain roots in user input → FINDING.
Example: authority validated against vault.authority, vault validated against PDA seeds → chain roots in PDA (good).

Finding Template

**ID**: [AV-N]
**Severity**: [based on what attacker can do with invalid account]
**Step Execution**: ✓1,2,3,4,5,6,7,8 | ✗(reasons) | ?(uncertain)
**Rules Applied**: [S1:✓, S6:✓/✗, S7:✓/✗, S8:✓/✗, R4:✓/✗]
**Location**: program/src/instructions/{file}.rs:LineN
**Title**: Missing [validation type] for [account] in [instruction] enables [attack]
**Description**: [Specific missing validation with code reference]
**Impact**: [What attacker can achieve: fund theft, state corruption, DoS]

Step Execution Checklist (MANDATORY)