Substrate Vulnerability Scanner

1. Purpose

Systematically scan Substrate runtime modules (pallets) for platform-specific security vulnerabilities that can cause node crashes, DoS attacks, or unauthorized access. This skill encodes 7 critical vulnerability patterns unique to Substrate/FRAME-based chains.

2. When to Use This Skill

• Auditing custom Substrate pallets

• Reviewing FRAME runtime code

• Pre-launch security assessment of Substrate chains (Polkadot parachains, standalone chains)

• Validating dispatchable extrinsic functions

• Reviewing weight calculation functions

• Assessing unsigned transaction validation logic

3. Platform Detection

File Extensions & Indicators

• Rust files: .rs

Language/Framework Markers

// Substrate/FRAME indicators #[pallet] pub mod pallet { use frame_support::pallet_prelude::; use frame_system::pallet_prelude::;

#[pallet::config]
pub trait Config: frame_system::Config { }

#[pallet::call]
impl<T: Config> Pallet<T> {
    #[pallet::weight(10_000)]
    pub fn example_function(origin: OriginFor<T>) -> DispatchResult { }
}

}

// Common patterns DispatchResult, DispatchError ensure!, ensure_signed, ensure_root StorageValue, StorageMap, StorageDoubleMap #[pallet::storage] #[pallet::call] #[pallet::weight] #[pallet::validate_unsigned]

Project Structure

• pallets/*/lib.rs

• Pallet implementations

• runtime/lib.rs

• Runtime configuration

• benchmarking.rs

• Weight benchmarks

• Cargo.toml with frame-* dependencies

Tool Support

• cargo-fuzz: Fuzz testing for Rust

• test-fuzz: Property-based testing framework

• benchmarking framework: Built-in weight calculation

• try-runtime: Runtime migration testing

4. How This Skill Works

When invoked, I will:

• Search your codebase for Substrate pallets

• Analyze each pallet for the 7 vulnerability patterns

• Report findings with file references and severity

• Provide fixes for each identified issue

• Check weight calculations and origin validation

5. Vulnerability Patterns (7 Critical Patterns)

I check for 7 critical vulnerability patterns unique to Substrate/FRAME. For detailed detection patterns, code examples, mitigations, and testing strategies, see VULNERABILITY_PATTERNS.md.

Pattern Summary:

Arithmetic Overflow ⚠️ CRITICAL

• Direct + , - , * , / operators wrap in release mode

• Must use checked_* or saturating_* methods

• Affects balance/token calculations, reward/fee math

Don't Panic ⚠️ CRITICAL - DoS

• Panics cause node to stop processing blocks

• No unwrap() , expect() , array indexing without bounds check

• All user input must be validated with ensure!

Weights and Fees ⚠️ CRITICAL - DoS

• Incorrect weights allow spam attacks

• Fixed weights for variable-cost operations enable DoS

• Must use benchmarking framework, bound all input parameters

Verify First, Write Last ⚠️ HIGH (Pre-v0.9.25)

• Storage writes before validation persist on error (pre-v0.9.25)

• Pattern: validate → write → emit event

• Upgrade to v0.9.25+ or use manual #[transactional]

Unsigned Transaction Validation ⚠️ HIGH

• Insufficient validation allows spam/replay attacks

• Prefer signed transactions

• If unsigned: validate parameters, replay protection, authenticate source

Bad Randomness ⚠️ MEDIUM

• pallet_randomness_collective_flip vulnerable to collusion

• Must use BABE randomness (pallet_babe::RandomnessFromOneEpochAgo )

• Use random(subject) not random_seed()

Bad Origin ⚠️ CRITICAL

• ensure_signed allows any user for privileged operations

• Must use ensure_root or custom origins (ForceOrigin, AdminOrigin)

• Origin types must be properly configured in runtime

For complete vulnerability patterns with code examples, see VULNERABILITY_PATTERNS.md.

6. Scanning Workflow

Step 1: Platform Identification

• Verify Substrate/FRAME framework usage

• Check Substrate version (v0.9.25+ has transactional storage)

• Locate pallet implementations (pallets/*/lib.rs )

• Identify runtime configuration (runtime/lib.rs )

Step 2: Dispatchable Analysis

For each #[pallet::call] function:

• Arithmetic: Uses checked/saturating operations?

• Panics: No unwrap/expect/indexing?

• Weights: Proportional to cost, bounded inputs?

• Origin: Appropriate validation level?

• Validation: All checks before storage writes?

Step 3: Panic Sweep

Search for panic-prone patterns

rg "unwrap()" pallets/ rg "expect(" pallets/ rg "[.*]" pallets/ # Array indexing rg " as u\d+" pallets/ # Type casts rg ".unwrap_or" pallets/

Step 4: Arithmetic Safety Check

Find direct arithmetic

rg " + |+=| - |-=| * |*=| / |/=" pallets/

Should find checked/saturating alternatives instead

rg "checked_add|checked_sub|checked_mul|checked_div" pallets/ rg "saturating_add|saturating_sub|saturating_mul" pallets/

Step 5: Weight Analysis

• Run benchmarking: cargo test --features runtime-benchmarks

• Verify weights match computational cost

• Check for bounded input parameters

• Review weight calculation functions

Step 6: Origin & Privilege Review

Find privileged operations

rg "ensure_signed" pallets/ | grep -E "pause|emergency|admin|force|sudo"

Should use ensure_root or custom origins

rg "ensure_root|ForceOrigin|AdminOrigin" pallets/

Step 7: Testing Review

• Unit tests cover all dispatchables

• Fuzz tests for panic conditions

• Benchmarks for weight calculation

• try-runtime tests for migrations

7. Priority Guidelines

Critical (Immediate Fix Required)

• Arithmetic overflow (token creation, balance manipulation)

• Panic DoS (node crash risk)

• Bad origin (unauthorized privileged operations)

High (Fix Before Launch)

• Incorrect weights (DoS via spam)

• Verify-first violations (state corruption, pre-v0.9.25)

• Unsigned validation issues (spam, replay attacks)

Medium (Address in Audit)

• Bad randomness (manipulation possible but limited impact)

8. Testing Recommendations

Fuzz Testing

// Use test-fuzz for property-based testing #[cfg(test)] mod tests { use test_fuzz::test_fuzz;

#[test_fuzz]
fn fuzz_transfer(from: AccountId, to: AccountId, amount: u128) {
    // Should never panic
    let _ = Pallet::transfer(from, to, amount);
}

#[test_fuzz]
fn fuzz_no_panics(call: Call) {
    // No dispatchable should panic
    let _ = call.dispatch(origin);
}

}

Benchmarking

Run benchmarks to generate weights

cargo build --release --features runtime-benchmarks ./target/release/node benchmark pallet
--chain dev
--pallet pallet_example
--extrinsic "*"
--steps 50
--repeat 20

try-runtime

Test runtime upgrades

cargo build --release --features try-runtime try-runtime --runtime ./target/release/wbuild/runtime.wasm
on-runtime-upgrade live --uri wss://rpc.polkadot.io

9. Additional Resources

• Building Secure Contracts: building-secure-contracts/not-so-smart-contracts/substrate/

• Substrate Documentation: https://docs.substrate.io/

• FRAME Documentation: https://paritytech.github.io/substrate/master/frame_support/

• test-fuzz: https://github.com/trailofbits/test-fuzz

• Substrate StackExchange: https://substrate.stackexchange.com/

10. Quick Reference Checklist

Before completing Substrate pallet audit:

Arithmetic Safety (CRITICAL):

• No direct + , - , * , / operators in dispatchables

• All arithmetic uses checked_* or saturating_*

• Type conversions use try_into() with error handling

Panic Prevention (CRITICAL):

• No unwrap() or expect() in dispatchables

• No direct array/slice indexing without bounds check

• All user inputs validated with ensure!

• Division operations check for zero divisor

Weights & DoS (CRITICAL):

• Weights proportional to computational cost

• Input parameters have maximum bounds

• Benchmarking used to determine weights

• No free (zero-weight) expensive operations

Access Control (CRITICAL):

• Privileged operations use ensure_root or custom origins

• ensure_signed only for user-level operations

• Origin types properly configured in runtime

• Sudo pallet removed before production

Storage Safety (HIGH):

• Using Substrate v0.9.25+ OR manual #[transactional]

• Validation before storage writes

• Events emitted after successful operations

Other (MEDIUM):

• Unsigned transactions use signed alternative if possible

• If unsigned: proper validation, replay protection, authentication

• BABE randomness used (not RandomnessCollectiveFlip)

• Randomness uses random(subject) not random_seed()

Testing:

• Unit tests for all dispatchables

• Fuzz tests to find panics

• Benchmarks generated and verified

• try-runtime tests for migrations