anchor-audit 0.1.0

package/rules/043-account-vs-account-info.md

@@ -0,0 +1,53 @@
+# Rule 043: `Account` vs `AccountInfo` Misuse
+
+**Severity:** High
+**Category:** Constraints
+
+## Description
+Choosing `AccountInfo<'info>` / `UncheckedAccount<'info>` where `Account<'info, T>` (or a typed wrapper like `Program`, `Signer`, `Sysvar`, `InterfaceAccount`) belongs throws away Anchor's automatic validation: owner check, discriminator check, and deserialization. Reaching for the untyped variant "to make it compile" silently disables the protections that prevent owner-spoofing (Rule 002) and type-cosplay (Rule 003).
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Use<'info> {
+    /// CHECK: it's our config
+    pub config: AccountInfo<'info>, // no owner/discriminator/type check
+    pub user: Signer<'info>,
+}
+
+pub fn use_config(ctx: Context<Use>) -> Result<()> {
+    let config = Config::try_from_slice(&ctx.accounts.config.data.borrow())?; // unsafe
+    require_keys_eq!(config.admin, ctx.accounts.user.key());
+    Ok(())
+}
+```
+
+## Why this is dangerous
+With `AccountInfo`, nothing verifies that `config` is owned by this program or is actually a `Config` — the attacker forges its bytes (Rule 002) or passes a different account type with a compatible layout (Rule 003). The single type choice is the difference between Anchor enforcing three invariants and the program enforcing none.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Use<'info> {
+    // Account<'info, Config> checks owner == program ID, discriminator, and
+    // deserializes safely.
+    #[account(has_one = admin)]
+    pub config: Account<'info, Config>,
+    pub admin: Signer<'info>,
+}
+```
+Reserve `AccountInfo`/`UncheckedAccount` for genuinely opaque accounts, and when used, document the manual checks in the `/// CHECK:` comment and perform them.
+
+## Detection heuristic
+- `AccountInfo`/`UncheckedAccount` whose data is deserialized into a known program type
+- `/// CHECK:` comments that don't describe a real, performed validation
+- Program/token/sysvar accounts typed as `AccountInfo` instead of `Program`/`Account<TokenAccount>`/`Sysvar`
+- Typed wrappers avoided "to fix a lifetime/borrow error" without restoring the checks manually
+
+## References
+- Anchor docs — account types (https://www.anchor-lang.com/docs/account-types)
+- The Anchor Book — AccountInfo and UncheckedAccount (https://book.anchor-lang.com/anchor_in_depth/the_accounts_struct.html)
+- Neodyme — Solana common pitfalls (https://neodyme.io/en/blog/solana_common_pitfalls/)
+
+## Real-world exploits (if any)
+No single attributed exploit for the type choice alone; it is the enabling mistake behind owner-check and type-cosplay exploits (Rules 002, 003) repeatedly flagged in audits.

package/rules/044-token-account-owner-unverified.md

@@ -0,0 +1,56 @@
+# Rule 044: Token Account Owner Unverified
+
+**Severity:** High
+**Category:** SPL Token
+
+## Description
+An SPL token account has an `owner` field (the wallet/PDA authority that controls it) distinct from the account's program owner. Code that accepts a token account and acts on it — crediting a user, treating it as a vault — without verifying its `owner` matches the expected authority lets an attacker pass a token account controlled by someone else, or by the program when it shouldn't be.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Stake<'info> {
+    pub user: Signer<'info>,
+    // No check that user_token.owner == user.key()
+    #[account(mut)]
+    pub user_token: Account<'info, TokenAccount>,
+    #[account(mut)]
+    pub stake_account: Account<'info, StakeAccount>,
+}
+
+pub fn stake(ctx: Context<Stake>, amount: u64) -> Result<()> {
+    // Credits the signer based on a token account they may not own
+    ctx.accounts.stake_account.staked += amount;
+    Ok(())
+}
+```
+
+## Why this is dangerous
+The attacker references a token account they don't control (or whose balance they can't actually move) to claim staking credit, or substitutes the program's own vault as the "source" to get credited without depositing. The token account's `owner`/`authority` must be tied to the principal the instruction credits or debits.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Stake<'info> {
+    pub user: Signer<'info>,
+    #[account(mut, token::authority = user)] // owner must be `user`
+    pub user_token: Account<'info, TokenAccount>,
+    #[account(mut, has_one = user)]
+    pub stake_account: Account<'info, StakeAccount>,
+}
+```
+Use `token::authority = ...` (or check `token_account.owner == expected`) on every token account whose control matters.
+
+## Detection heuristic
+- `Account<'info, TokenAccount>` used in logic without `token::authority` / an `owner` equality check
+- Crediting/debiting a principal based on a token account not constrained to that principal
+- Vault/source token accounts not pinned via `token::authority = <pda>` or `address =`
+- `.owner` of a token account read but compared to nothing
+
+## References
+- anchor_spl docs — token::authority constraint (https://docs.rs/anchor-spl/latest/anchor_spl/)
+- SPL Token docs — account owner vs authority (https://spl.solana.com/token)
+- Neodyme — Solana common pitfalls (https://neodyme.io/en/blog/solana_common_pitfalls/)
+
+## Real-world exploits (if any)
+No single attributed public headline exploit; unverified token-account ownership is a frequent high-severity audit finding in staking and vault programs.

package/rules/045-token-mint-unverified.md

@@ -0,0 +1,58 @@
+# Rule 045: Token Mint Unverified
+
+**Severity:** High
+**Category:** SPL Token
+
+## Description
+A token account is tied to exactly one mint, but code that accepts "a token account" without constraining its `mint` allows an attacker to pass an account for a *different*, worthless mint. The program credits or values the deposit as if it were the expected (valuable) token, because it never checked which token the account actually holds.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Deposit<'info> {
+    pub user: Signer<'info>,
+    // No check that user_token.mint == expected USDC mint
+    #[account(mut)]
+    pub user_token: Account<'info, TokenAccount>,
+    #[account(mut)]
+    pub vault: Account<'info, TokenAccount>,
+}
+
+pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
+    // Transfers `amount` of WHATEVER mint user_token holds, credits as USDC
+    token::transfer(/* user_token -> vault */, amount)?;
+    ctx.accounts.position.usdc_balance += amount;
+    Ok(())
+}
+```
+
+## Why this is dangerous
+The attacker mints a worthless token, deposits it, and is credited a USDC balance one-for-one, then withdraws real USDC. Without a mint check, the program cannot tell a valuable token from a fake one. The transfer must also target a vault of the *same* mint, or accounting diverges from the actual held assets.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Deposit<'info> {
+    pub user: Signer<'info>,
+    #[account(mut, token::mint = usdc_mint, token::authority = user)]
+    pub user_token: Account<'info, TokenAccount>,
+    #[account(mut, token::mint = usdc_mint)]
+    pub vault: Account<'info, TokenAccount>,
+    #[account(address = config.usdc_mint)]
+    pub usdc_mint: Account<'info, Mint>,
+}
+```
+
+## Detection heuristic
+- Token accounts used without a `token::mint = ...` constraint or `.mint` equality check
+- Deposit/withdraw/swap logic that credits a specific asset from an unconstrained token account
+- Vault and user token accounts not constrained to the *same* expected mint
+- A `Mint` account referenced but never pinned via `address =` to the configured mint
+
+## References
+- anchor_spl docs — token::mint constraint (https://docs.rs/anchor-spl/latest/anchor_spl/)
+- SPL Token docs — token account mint binding (https://spl.solana.com/token)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+
+## Real-world exploits (if any)
+No single attributed public headline exploit; missing mint validation is a recurring high/critical finding in audits of deposit-based DeFi programs.

package/rules/046-ata-assumption-errors.md

@@ -0,0 +1,53 @@
+# Rule 046: Associated Token Account Assumption Errors
+
+**Severity:** Medium
+**Category:** SPL Token
+
+## Description
+Code assumes a token account is *the* canonical associated token account (ATA) for a given wallet+mint — correctly derived, already existing, and the only one — without enforcing it. A wallet can hold many token accounts for the same mint, and only the ATA is at the deterministic derived address. Trusting an unconstrained "ATA" lets an attacker pass a non-canonical token account, and assuming existence causes failures or, worse, silent misrouting.
+
+## Vulnerable pattern
+```rust
+#[derive(Accounts)]
+pub struct Payout<'info> {
+    /// CHECK: assumed to be the recipient's ATA, but not derived/verified
+    #[account(mut)]
+    pub recipient_ata: AccountInfo<'info>,
+    pub recipient: SystemAccount<'info>,
+    pub mint: Account<'info, Mint>,
+    // ...
+}
+```
+
+## Why this is dangerous
+The attacker passes a token account they control (for the right mint but at a non-ATA address, or owned by a different wallet) as `recipient_ata`, redirecting a payout. Conversely, assuming the ATA already exists makes the instruction fail when it doesn't, bricking the flow — or pushes developers to create it without checking who pays. ATA identity must be derived and checked, not assumed.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct Payout<'info> {
+    #[account(
+        mut,
+        associated_token::mint = mint,
+        associated_token::authority = recipient, // enforces canonical ATA
+    )]
+    pub recipient_ata: Account<'info, TokenAccount>,
+    pub recipient: SystemAccount<'info>,
+    pub mint: Account<'info, Mint>,
+    // For creation: use `init` with associated_token::* + the ATA program.
+}
+```
+
+## Detection heuristic
+- Accounts named `*_ata` typed as `AccountInfo` or `TokenAccount` without `associated_token::*` constraints
+- Token destinations assumed canonical without `associated_token::mint`/`authority` (or a `get_associated_token_address` comparison)
+- Code that assumes an ATA exists with no `init`/`init_if_needed` or existence handling
+- ATA derivation done off-chain and trusted on-chain without re-derivation
+
+## References
+- anchor_spl docs — associated_token constraints (https://docs.rs/anchor-spl/latest/anchor_spl/associated_token/)
+- SPL Associated Token Account program docs (https://spl.solana.com/associated-token-account)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+
+## Real-world exploits (if any)
+No single attributed public exploit; ATA assumption errors are common medium audit findings, especially payout redirection via non-canonical token accounts.

package/rules/047-token-program-id-hardcoded.md

@@ -0,0 +1,55 @@
+# Rule 047: Token Program ID Hardcoded vs. Validated
+
+**Severity:** Medium
+**Category:** SPL Token
+
+## Description
+With SPL Token and Token-2022 both in use, a program must be deliberate about which token program it targets. Two failure modes: (1) hardcoding `spl_token::ID` while accepting mints/accounts that actually belong to Token-2022 (or vice-versa), causing CPI failures or wrong assumptions; and (2) accepting the token program as an unvalidated account so the wrong (or fake) program is used. The program ID must match the program that actually owns the token accounts involved.
+
+## Vulnerable pattern
+```rust
+pub fn transfer_out(ctx: Context<TransferOut>, amount: u64) -> Result<()> {
+    // Hardcodes legacy SPL Token, but the mint is a Token-2022 mint, so the
+    // accounts are owned by the Token-2022 program — this CPI targets the
+    // wrong program ID for these accounts.
+    let cpi = CpiContext::new(
+        ctx.accounts.token_program.to_account_info(), // assumed spl_token::ID
+        Transfer { /* ... */ },
+    );
+    token::transfer(cpi, amount)?;
+    Ok(())
+}
+```
+
+## Why this is dangerous
+Mismatching the token program against the token accounts' actual owner program makes transfers fail (availability) or, when combined with unvalidated program accounts, lets a fake token program be injected (Rule 019). Hardcoding one variant silently breaks compatibility for the other and can be steered by an attacker choosing a Token-2022 mint where SPL Token is assumed.
+
+## Fix pattern
+```rust
+#[derive(Accounts)]
+pub struct TransferOut<'info> {
+    // Interface accepts either SPL Token or Token-2022, verified to match
+    // the accounts' owning program.
+    pub token_program: Interface<'info, TokenInterface>,
+    #[account(mut)]
+    pub from: InterfaceAccount<'info, TokenAccount>,
+    #[account(mut)]
+    pub to: InterfaceAccount<'info, TokenAccount>,
+    pub authority: Signer<'info>,
+}
+// Use anchor_spl::token_interface CPIs so the call routes to the correct program.
+```
+
+## Detection heuristic
+- Hardcoded `spl_token::ID` / `Program<'info, Token>` while the program intends to support Token-2022 (or vice-versa)
+- Token accounts as `Account<TokenAccount>` (legacy) when mints may be Token-2022 — use `InterfaceAccount`
+- Token program passed as `AccountInfo` without an ID check (overlaps Rule 019)
+- No verification that `token_program.key()` equals the owner program of the passed token accounts
+
+## References
+- anchor_spl docs — token_interface / Interface (https://docs.rs/anchor-spl/latest/anchor_spl/token_interface/)
+- SPL Token-2022 docs (https://spl.solana.com/token-2022)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+
+## Real-world exploits (if any)
+No single attributed public exploit; token-program mismatch and Token-2022 compatibility gaps are increasingly common medium audit findings.

package/rules/048-compute-budget-abuse.md

@@ -0,0 +1,51 @@
+# Rule 048: Compute Budget Abuse (Unbounded Work)
+
+**Severity:** Medium
+**Category:** Runtime
+
+## Description
+Each Solana transaction has a compute-unit budget. An instruction that iterates over an attacker-controllable, unbounded collection — `remaining_accounts`, a `Vec` field that can grow without limit, or a loop whose count comes from input — can be pushed to exceed the budget and fail. If a critical operation (liquidation, settlement, crank) lives behind such a loop, the attacker grows the data until the operation can no longer complete, a denial-of-service.
+
+## Vulnerable pattern
+```rust
+pub fn distribute(ctx: Context<Distribute>) -> Result<()> {
+    // `holders` can grow unboundedly as users join; eventually this loop
+    // exceeds the compute budget and every distribute() call fails.
+    for holder in ctx.accounts.registry.holders.iter() {
+        pay(holder)?;
+    }
+    Ok(())
+}
+```
+
+## Why this is dangerous
+Once the collection is large enough, the instruction always runs out of compute and reverts, permanently bricking the path. If liquidations or withdrawals depend on it, funds can be frozen. An attacker may intentionally inflate the collection (cheap entries) to trigger the DoS, or simply rely on organic growth crossing the limit.
+
+## Fix pattern
+```rust
+// Paginate / bound the work per call, tracking progress in state:
+pub fn distribute(ctx: Context<Distribute>, start: u32, count: u32) -> Result<()> {
+    require!(count <= MAX_PER_CALL, ErrorCode::BatchTooLarge);
+    let end = (start + count).min(ctx.accounts.registry.holders.len() as u32);
+    for i in start..end {
+        pay(&ctx.accounts.registry.holders[i as usize])?;
+    }
+    ctx.accounts.registry.cursor = end;
+    Ok(())
+}
+```
+Cap collection sizes at insertion and design cranks to process bounded batches.
+
+## Detection heuristic
+- Loops over `remaining_accounts`, `Vec`/`String` fields, or input-controlled counts with no per-call cap
+- Account structs holding unbounded collections that are iterated in a single instruction
+- Critical operations (liquidate, settle, distribute) gated behind whole-collection iteration
+- No pagination/cursor for processing large datasets
+
+## References
+- Solana docs — compute budget and limits (https://solana.com/docs/core/fees#compute-budget)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Sec3 — denial-of-service via compute exhaustion (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; unbounded-iteration DoS is a recognized medium audit finding for registries, reward distributors, and cranks.

package/rules/049-log-spam-dos.md

@@ -0,0 +1,49 @@
+# Rule 049: Log Spam / Excessive Logging DoS
+
+**Severity:** Low
+**Category:** Runtime
+
+## Description
+`msg!` and other logging consume compute units and contribute to transaction log size, which is itself bounded. Logging attacker-controlled or unbounded data (a user-supplied string, every element of a collection, large buffers) lets an attacker inflate compute/log usage to make an instruction fail, or simply wastes the budget so legitimately-needed work no longer fits. Logging inside hot loops compounds the cost.
+
+## Vulnerable pattern
+```rust
+pub fn record(ctx: Context<Record>, memo: String) -> Result<()> {
+    // Attacker-controlled, unbounded string logged verbatim; large memos
+    // burn compute and bloat logs, and can push the tx over its limits.
+    msg!("memo: {}", memo);
+    for item in ctx.accounts.list.items.iter() {
+        msg!("item: {:?}", item); // logging in a loop multiplies the cost
+    }
+    Ok(())
+}
+```
+
+## Why this is dangerous
+Excessive logging can exhaust the compute budget (causing the instruction to fail) and inflate transaction logs, degrading RPC/indexer performance for everyone reading the program's output. When a required instruction logs unbounded input, an attacker can deny its use; even absent an attacker, it raises costs and can intermittently break the path.
+
+## Fix pattern
+```rust
+pub fn record(ctx: Context<Record>, memo: String) -> Result<()> {
+    require!(memo.len() <= MAX_MEMO_LEN, ErrorCode::MemoTooLong);
+    // Avoid logging raw user data; log bounded, structured summaries only.
+    msg!("record: memo_len={}", memo.len());
+    // Do not log inside large loops; emit a single summary if needed.
+    Ok(())
+}
+```
+Prefer structured Anchor events (`emit!`) over verbose `msg!`, and never log full attacker-controlled buffers.
+
+## Detection heuristic
+- `msg!` formatting attacker-controlled strings/buffers without a length cap
+- Logging inside loops over collections or `remaining_accounts`
+- Verbose debug logging (`{:?}` on large structs) left in production paths
+- No bound on user-supplied fields that are subsequently logged
+
+## References
+- Solana docs — program logging and limits (https://solana.com/docs/programs/debugging#logging)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+- Sec3 — compute and log DoS (https://www.sec3.dev/blog)
+
+## Real-world exploits (if any)
+No single attributed public exploit; log/compute spam is a low-severity hygiene and availability finding in audits.

package/rules/050-stack-overflow-deep-cpi.md

@@ -0,0 +1,48 @@
+# Rule 050: Stack / CPI Depth Exhaustion
+
+**Severity:** Low
+**Category:** Runtime
+
+## Description
+The Solana runtime caps cross-program invocation depth (CPI calls can nest only a limited number of levels) and each program has a bounded stack frame size (large stack-allocated structures/arrays can blow the frame). Designs that chain many CPIs, or that place large data on the stack (especially recursively or in deep call chains), can hit these limits and fail at runtime — bricking instructions that depend on the full chain.
+
+## Vulnerable pattern
+```rust
+// Deeply nested CPI chain: A -> B -> C -> D ... approaching the CPI depth
+// limit. If the chain needs one more hop than allowed, the whole flow fails.
+pub fn route(ctx: Context<Route>) -> Result<()> {
+    invoke(&next_program_ix, accounts)?; // which itself CPIs further down
+    Ok(())
+}
+
+// Large stack allocation inside a call that's already deep in a CPI chain:
+let buffer = [0u8; 16_384]; // big stack frame, risks stack overflow
+```
+
+## Why this is dangerous
+If an operation's success depends on a CPI chain near the depth limit, any addition (a new integration, a wrapper) tips it over and the instruction reverts — an availability failure that can freeze dependent funds. Oversized stack frames in deep chains can abort the program. Attackers may also craft inputs that force the deepest path.
+
+## Fix pattern
+```rust
+// Keep CPI chains shallow; flatten orchestration into the top-level program
+// rather than relaying through intermediate programs where avoidable.
+// Move large data off the stack onto the heap or into accounts:
+let buffer = vec![0u8; 16_384]; // heap-allocated; small stack frame
+
+// Process multi-step flows as separate top-level instructions instead of
+// one deep nested chain.
+```
+
+## Detection heuristic
+- CPI chains that relay through several intermediate programs (each adding a level)
+- Large fixed-size arrays/structs allocated on the stack (`[u8; N]`, big local structs), especially in deep call paths or recursion
+- Recursive program logic without a strict depth bound
+- Designs assuming an arbitrary number of nested CPIs will succeed
+
+## References
+- Solana docs — CPI depth and stack limits (https://solana.com/docs/core/cpi)
+- Solana docs — program runtime limits (https://docs.solanalabs.com/runtime/programming-model/runtime)
+- Helius — A Hitchhiker's Guide to Solana Program Security (https://www.helius.dev/blog/a-hitchhikers-guide-to-solana-program-security)
+
+## Real-world exploits (if any)
+No single attributed public exploit; depth/stack limits surface as availability/robustness findings in audits of programs with deep integration chains.

package/rules/INDEX.md

@@ -0,0 +1,65 @@
+# Rule index
+
+50 rules across 8 categories. Severity reflects typical impact when the pattern is present and exploitable; always judge in context.
+
+| ID | Rule | Severity | Category |
+|----|------|----------|----------|
+| 001 | [Missing signer check](./001-missing-signer-check.md) | Critical | Account validation |
+| 002 | [Missing owner check](./002-missing-owner-check.md) | Critical | Account validation |
+| 003 | [Missing discriminator check (type cosplay)](./003-missing-discriminator-check.md) | High | Account validation |
+| 004 | [Account substitution](./004-account-substitution.md) | High | Account validation |
+| 005 | [Sysvar spoofing](./005-sysvar-spoofing.md) | High | Account validation |
+| 006 | [Missing rent-exemption check](./006-missing-rent-exemption-check.md) | Low | Account validation |
+| 007 | [Account aliasing (duplicate mutable accounts)](./007-account-aliasing.md) | High | Account validation |
+| 008 | [Uninitialized account use](./008-uninitialized-account-use.md) | High | Account validation |
+| 009 | [Missing `mut` constraint](./009-missing-mut-constraint.md) | Medium | Account validation |
+| 010 | [Missing or improper close constraint](./010-missing-close-constraint.md) | Medium | Account validation |
+| 011 | [PDA seed collision](./011-pda-seed-collision.md) | High | PDA |
+| 012 | [Missing bump validation](./012-missing-bump-validation.md) | Medium | PDA |
+| 013 | [Non-canonical bump accepted](./013-non-canonical-bump-accepted.md) | High | PDA |
+| 014 | [Predictable / attacker-controlled PDA seeds](./014-predictable-pda.md) | High | PDA |
+| 015 | [Insecure PDA layout across upgrades](./015-insecure-pda-across-upgrades.md) | Medium | PDA |
+| 016 | [Stored bump mismatch](./016-bump-mismatch.md) | Medium | PDA |
+| 017 | [Arbitrary CPI (unvalidated target)](./017-arbitrary-cpi.md) | Critical | CPI |
+| 018 | [CPI confused deputy](./018-cpi-confused-deputy.md) | High | CPI |
+| 019 | [Missing program ID check on SPL CPIs](./019-missing-program-id-check-spl.md) | High | CPI |
+| 020 | [Reentrancy via CPI](./020-reentrancy-via-cpi.md) | High | CPI |
+| 021 | [Untrusted callback execution](./021-untrusted-callback.md) | High | CPI |
+| 022 | [CPI invoked with attacker-controlled accounts](./022-cpi-with-attacker-accounts.md) | High | CPI |
+| 023 | [Lamport arithmetic overflow / underflow](./023-lamport-overflow.md) | High | Math |
+| 024 | [Token amount arithmetic overflow](./024-token-amount-overflow.md) | High | Math |
+| 025 | [Precision loss (division before multiplication)](./025-precision-loss.md) | Medium | Math |
+| 026 | [Incorrect rounding direction](./026-rounding-direction.md) | Medium | Math |
+| 027 | [Token decimal mismatch](./027-token-decimal-mismatch.md) | Medium | Math |
+| 028 | [Integer cast truncation](./028-integer-cast-truncation.md) | Medium | Math |
+| 029 | [Off-by-one errors](./029-off-by-one.md) | Low | Math |
+| 030 | [Missing authorization on privileged instruction](./030-missing-authorization.md) | Critical | Auth |
+| 031 | [Reinitialization attack](./031-reinitialization-attack.md) | High | Auth |
+| 032 | [Closed account revival](./032-closed-account-revival.md) | High | Auth |
+| 033 | [`init_if_needed` misuse](./033-init-if-needed-misuse.md) | High | Auth |
+| 034 | [Missing `has_one` relationship enforcement](./034-missing-has-one.md) | High | Auth |
+| 035 | [Insecure admin transfer (no acceptance handshake)](./035-insecure-admin-transfer.md) | Medium | Auth |
+| 036 | [Missing pause / freeze guards](./036-missing-pause-guards.md) | Low | Auth |
+| 037 | [Clock / time-based logic without bounds](./037-clock-manipulation.md) | Medium | Auth |
+| 038 | [Missing `address` validation on fixed-identity accounts](./038-missing-address-validation.md) | Medium | Constraints |
+| 039 | [Constraint evaluation stage (pre- vs post-state)](./039-constraint-evaluation-stage.md) | Medium | Constraints |
+| 040 | [`realloc` without zero-init](./040-realloc-zero-init.md) | Medium | Constraints |
+| 041 | [`init` without `payer` (or wrong payer)](./041-missing-payer-on-init.md) | Low | Constraints |
+| 042 | [Incorrect `space` allocation](./042-incorrect-space-allocation.md) | Medium | Constraints |
+| 043 | [`Account` vs `AccountInfo` misuse](./043-account-vs-account-info.md) | High | Constraints |
+| 044 | [Token account owner unverified](./044-token-account-owner-unverified.md) | High | SPL Token |
+| 045 | [Token mint unverified](./045-token-mint-unverified.md) | High | SPL Token |
+| 046 | [Associated token account assumption errors](./046-ata-assumption-errors.md) | Medium | SPL Token |
+| 047 | [Token program ID hardcoded vs. validated](./047-token-program-id-hardcoded.md) | Medium | SPL Token |
+| 048 | [Compute budget abuse (unbounded work)](./048-compute-budget-abuse.md) | Medium | Runtime |
+| 049 | [Log spam / excessive logging DoS](./049-log-spam-dos.md) | Low | Runtime |
+| 050 | [Stack / CPI depth exhaustion](./050-stack-overflow-deep-cpi.md) | Low | Runtime |
+
+## Severity counts
+
+| Severity | Count |
+|----------|-------|
+| Critical | 4 |
+| High | 21 |
+| Medium | 17 |
+| Low | 8 |

package/rules/README.md

@@ -0,0 +1,40 @@
+# Rule catalog
+
+One markdown file per rule, named `NNN-kebab-case-name.md` (e.g. `001-missing-signer-check.md`). The full list with severities lives in [INDEX.md](./INDEX.md).
+
+The catalog is consumed by both the Claude Code skill ([SKILL.md](../SKILL.md)) and the CLI (`cli/src/rules-loader.ts`), so every file must follow this exact template:
+
+````markdown
+# Rule NNN: <Title>
+
+**Severity:** Critical | High | Medium | Low
+**Category:** Account validation | PDA | CPI | Math | Auth | Constraints | SPL Token | Runtime
+
+## Description
+One paragraph explaining the vulnerability and why it matters.
+
+## Vulnerable pattern
+```rust
+// Minimal Rust/Anchor snippet showing the bug
+```
+
+## Why this is dangerous
+Explain attacker action and impact in 2 to 4 sentences.
+
+## Fix pattern
+```rust
+// Minimal Rust/Anchor snippet showing the corrected code
+```
+
+## Detection heuristic
+Bullet list of things an agent should look for in source code to flag this rule.
+
+## References
+- Source 1 (URL)
+- Source 2 (URL)
+
+## Real-world exploits (if any)
+Optional: brief mention of public exploits matching this pattern.
+````
+
+Content must be sourced (Neodyme, Sec3, Helius, Solana Cookbook, Cyfrin Updraft, the Anchor book, public audit reports) and cited in the References section — never invented.