/cairo-vulnerability-scanner

name: cairo-vulnerability-scanner
description: Scans Cairo/StarkNet smart contracts for 6 critical vulnerabilities including felt252 arithmetic overflow, L1-L2 messaging issues, address conversion problems, and signature replay. Use when auditing StarkNet projects.

Cairo/StarkNet Vulnerability Scanner

1. Purpose

Systematically scan Cairo smart contracts on StarkNet for platform-specific security vulnerabilities related to arithmetic, cross-layer messaging, and cryptographic operations. This skill encodes 6 critical vulnerability patterns unique to Cairo/StarkNet ecosystem.

2. When to Use This Skill

• Auditing StarkNet smart contracts (Cairo)
• Reviewing L1-L2 bridge implementations
• Pre-launch security assessment of StarkNet applications
• Validating cross-layer message handling
• Reviewing signature verification logic
• Assessing L1 handler functions

3. Platform Detection

File Extensions & Indicators

• **Cairo files**: `.cairo`

Language/Framework Markers

// Cairo contract indicators
#[contract]
mod MyContract {
    use starknet::ContractAddress;

    #[storage]
    struct Storage {
        balance: LegacyMap<ContractAddress, felt252>,
    }

    #[external(v0)]
    fn transfer(ref self: ContractState, to: ContractAddress, amount: felt252) {
        // Contract logic
    }

    #[l1_handler]
    fn handle_deposit(ref self: ContractState, from_address: felt252, amount: u256) {
        // L1 message handler
    }
}

// Common patterns
felt252, u128, u256
ContractAddress, EthAddress
#[external(v0)], #[l1_handler], #[constructor]
get_caller_address(), get_contract_address()
send_message_to_l1_syscall

Project Structure

• `src/contract.cairo` - Main contract implementation
• `src/lib.cairo` - Library modules
• `tests/` - Contract tests
• `Scarb.toml` - Cairo project configuration

Tool Support

• **Caracal**: Trail of Bits static analyzer for Cairo
• Installation: `cargo install --git https://github.com/crytic/caracal --profile release --force` (a Rust tool — not on PyPI)
• Usage: `caracal detect src/`
• **cairo-test**: Built-in testing framework
• **Starknet Foundry**: Testing and development toolkit

---

4. How This Skill Works

When invoked, I will:

1. **Search your codebase** for Cairo files 2. **Analyze each contract** for the 6 vulnerability patterns 3. **Report findings** with file references and severity, above them a coverage table carrying a verdict for every pattern 4. **Provide fixes** for each identified issue 5. **Check L1-L2 interactions** for messaging vulnerabilities

---

5. Example Output

When vulnerabilities are found, you'll get a report like this:

=== CAIRO/STARKNET VULNERABILITY SCAN RESULTS ===

---

6. Vulnerability Patterns (6 Patterns)

I check for 6 critical vulnerability patterns unique to Cairo/Starknet. For detailed detection patterns, code examples, mitigations, and testing strategies, see [VULNERABILITY_PATTERNS.md](resources/VULNERABILITY_PATTERNS.md).

Pattern Summary:

1. **Felt252 Arithmetic Overflow/Underflow** ⚠️ HIGH - `felt252` wraps silently; use `u128`/`u256` 2. **L1 to L2 Address Conversion** ⚠️ HIGH - L1 address not validated against STARKNET_FIELD_PRIME 3. **L1 to L2 Message Failure** ⚠️ HIGH - No cancellation path when a message cannot be consumed 4. **Overconstrained L1 <-> L2 Interaction** ⚠️ MEDIUM - Coupling that can strand funds or block progress 5. **Signature Replay Protection** ⚠️ HIGH - No nonce, or a domain separator missing chain/contract 6. **Unchecked from_address in L1 Handler** ⚠️ CRITICAL - Any L1 contract can drive the handler

For complete vulnerability patterns with code examples, see [VULNERABILITY_PATTERNS.md](resources/VULNERABILITY_PATTERNS.md).

7. Scanning Workflow

Step 1: Platform Identification

1. Verify Cairo language and StarkNet framework 2. Check Cairo version (Cairo 1.0+ vs legacy Cairo 0) 3. Locate contract files (`src/*.cairo`) 4. Identify L1-L2 bridge contracts (if applicable)

Step 2: Arithmetic Safety Sweep

# Find felt252 usage in arithmetic
rg "felt252" src/ | rg "[-+*/]"

# Find balance/amount storage using felt252
rg "felt252" src/ | rg "balance|amount|total|supply"

# Should prefer u128, u256 instead

Step 3: L1 Handler Analysis

For each `#[l1_handler]` function:

• [ ] Validates `from_address` parameter
• [ ] Checks address != zero
• [ ] Has proper access control
• [ ] Emits events for monitoring

Step 4: Signature Verification Review

For signature-based functions:

• [ ] Includes nonce tracking
• [ ] Nonce incremented after use
• [ ] Domain separator includes chain ID and contract address
• [ ] Cannot replay signatures

Step 5: L1-L2 Bridge Audit

If contract includes bridge functionality:

• [ ] L1 validates address < STARKNET_FIELD_PRIME
• [ ] L1 implements message cancellation
• [ ] L2 validates from_address in handlers
• [ ] Symmetric access controls L1 ↔ L2
• [ ] Test full roundtrip flows

Step 6: Static Analysis with Caracal

# Run Caracal detectors
caracal detect src/

# Specific detectors
caracal detect src/ --detectors unchecked-felt252-arithmetic
caracal detect src/ --detectors unchecked-l1-handler-from
caracal detect src/ --detectors missing-nonce-validation

---

8. Reporting Format

Coverage Table

Report on every pattern in §6, whether or not it turned anything up. Emit this table above the findings, with all 6 rows present:

| # | Pattern | Verdict | Evidence | |---|---------|---------|----------| | 1 | Felt252 Arithmetic Overflow/Underflow | `clear` | balances are `u256`; searched `felt252` in arithmetic, none | | 2 | L1 to L2 Address Conversion | | | | 3 | L1 to L2 Message Failure | | | | 4 | Overconstrained L1 <-> L2 Interaction | | | | 5 | Signature Replay Protection | | | | 6 | Unchecked from_address in L1 Handler | | |

Each verdict is one of:

• **`found`** — cite `file:line` and write the finding up in full below.
• **`clear`** — the pattern applies