exploitability-analyzer

# Exploitability Analyzer ## Mission Bridge the gap between “the defect exists” and “an attacker can exploit it.” Evaluate reachability, controllability, prerequisites, mitigations, reliability, economics, timing, victim interaction, deployment relevance, and impact realization. This skill must actively search for blockers and must not reward optimistic assumptions. ## Required inputs - Verified primitive and evidence. - Root-cause analysis. - Target scope and threat model. - Deployment/configuration profile. - Claimed impact and proposed attack path. ## Exploitability dimensions ### 1. Attacker position Classify the least-privileged realistic attacker: - remote unauthenticated; - authenticated ordinary user; - cross-tenant user; - malicious contract/token/peer; - relayer/oracle/validator subset; - local user; - administrator/insider; - compromised host or victim malware. ### 2. Reachability Confirm the production path from attacker input to primitive. Account for upstream proxies, gateways, middleware, feature flags, network topology, compile profile, and default configuration. ### 3. Controllability Determine exactly which values, ordering, timing, state, identities, signatures, balances, or messages the attacker controls. Partial control must not be treated as arbitrary control. ### 4. Preconditions List every prerequisite and classify: - attacker-provided; - naturally occurring; - victim-dependent; - privileged; - rare/race-dependent; - out-of-scope compromise; - economically acquired. ### 5. Mitigations and blockers Search for: - validation at another layer; - rate limits and quotas; - authentication/authorization binding; - sandboxing and process isolation; - supervisor restart and redundancy; - transaction reversion and atomicity; - slippage, liquidity, fees, finality, and MEV competition; - quorum, honest-majority, replay protection, and deterministic checks; - monitoring, circuit breakers, caps, timelocks, pause controls; - user warnings or explicit confirmations. ### 6. Reliability Measure or bound: - success rate; - attempts required; - timing window; - race reproducibility; - environmental sensitivity; - persistence; - ability to repeat or scale; - detectability and interruption risk. Do not use “reliable” without repeated evidence. ### 7. Impact realization Separate primitive from final impact: ```text verified primitive → intermediate capability → boundary crossed → measurable impact ``` Examples: - worker panic is not automatically service-wide DoS; - token disclosure is not automatically account takeover; - arbitrary external call is not automatically fund loss; - local state mismatch is not automatically consensus divergence; - temporary oracle deviation is not automatically extractable profit. ### 8. Economic and operational feasibility For Web3 record capital, liquidity, slippage, fees, gas, unwind, net value, transaction ordering, oracle windows, and recoverability. For Web2 record infrastructure scale, victim interaction, request volume, access durability, cloud permissions, and operational blast radius. ## Confidence caps Apply these maximum confidence values unless stronger evidence exists: - path not proven: 45; - attacker control inferred only: 55; - production configuration unknown: 60; - primitive reproduced but final impact not demonstrated: 70; - relies on rare race without statistics: 65; - requires excluded compromise or malware: classify threat-model mismatch; - economic profitability not modeled: 70 for financial impact; - consensus/network-wide effect not reproduced or formally established: 75. ## Verdicts - `PRACTICALLY_EXPLOITABLE` - `CONDITIONALLY_EXPLOITABLE` - `THEORETICAL_ONLY` - `BLOCKED_BY_MITIGATION` - `THREAT_MODEL_MISMATCH` - `INSUFFICIENT_EVIDENCE` ## Output Use `templates/exploitability-analysis.yaml`. Required next tests must be minimal, safe, and specific.