Vulnerability Detection Framework

The EVM vulnerability detection framework contains 136 specialized detectors organized across four severity tiers. Each detector runs on a high-level intermediate representation (HIR) of the contract and returns findings with severity, confidence, and location metadata.

Detection Architecture

The framework has three tiers:

Core framework: Defines the interface all detectors implement—name, description, severity level, and detection logic. The interface accepts a HIR of the contract and returns findings.

Analysis implementations: The 136 concrete detector implementations. Each implements analysis algorithms tailored to specific vulnerability patterns.

Detection orchestration: The public API providing detector registry, parallel execution, and result aggregation.

Analysis Techniques

Control Flow Analysis (CFG)

Used by: reentrancy, unchecked calls, access control detectors.

Constructs control flow graphs to trace execution paths and detect dangerous operation sequences. Graph algorithms identify paths where external calls precede state modifications, sensitive operations lack proper access checks, or return values are ignored on critical paths.

The reentrancy detector builds a CFG and searches for paths from CALL instructions to SSTORE operations, flagging functions where external calls can trigger state changes before completing.

Data Flow Analysis (DFA)

Used by: taint tracking, input validation, integer overflow detectors.

Tracks how data flows through the program to identify user-controlled data reaching sensitive operations, unvalidated inputs used in critical calculations, and arithmetic operations without overflow protection.

The arbitrary storage detector traces user input (CALLDATALOAD) through the program and flags any path where this data controls an SSTORE operation’s storage slot.

Symbolic Execution

Used by: oracle manipulation, division by zero, replay attack detectors.

Maintains symbolic values through execution to reason about possible value ranges, path feasibility, and edge cases. The division-by-zero detector symbolically tracks divisor values and identifies code paths where zero values are possible without protection.

Pattern Matching

Used by: flash loan, deprecated function, known exploit detectors.

Scans bytecode for known patterns using efficient sliding window algorithms—function selectors, opcode sequences characteristic of vulnerabilities, and historical exploit signatures. The flash loan detector scans bytecode for function selectors of Aave, Balancer, Uniswap V3, and dYdX flash loan functions in O(n) time.

Semantic Analysis

Used by: integer overflow (v0.8+), signature malleability, business logic detectors.

Understands program semantics by analyzing compiler version and built-in protections, standard patterns like OpenZeppelin guards, and business logic invariants. The integer overflow detector adjusts severity based on Solidity version—flagging unchecked blocks in 0.8+ while reporting all arithmetic in pre-0.8 contracts.

Call Graph Analysis

Used by: cross-function reentrancy, governance attack detectors.

Builds inter-procedural call graphs to detect cross-function state dependencies, multi-step attack chains, and complex interaction patterns. TheDAO-style cross-function reentrancy detection identifies when function A has an external call and function B modifies shared state, creating a vulnerability when A calls external code that re-enters B.

Historical Exploit Matching

All critical detectors draw from a database of real-world exploits covering 2016 through 2024, used to identify known attack patterns in new contracts, variations of historical vulnerabilities, and similar code structure to exploited contracts.

Detector Categories by Severity

Critical Severity — 35 Detectors

These identify vulnerabilities that enable direct fund theft, total contract compromise, or catastrophic failures.

Reentrancy Class (4 detectors)

Classic Reentrancy — external call before state update. CFG analysis finds CALL→SSTORE sequences. SWC-107. The original DAO hack pattern (approximately $60 million, 2016).

Cross-Function Reentrancy — function A calls external code, function B updates shared state, and the external code re-enters B before A completes. Detected via inter-procedural call graph analysis.

Read-Only Reentrancy — view function reads state during an external call when that state is inconsistent. Detects view/pure function calls within external calls. Relevant to Curve/Balancer oracle manipulation attacks.

Semantic Reentrancy — reentrancy through business logic rather than just storage ordering. Detected via invariant violation analysis; high false positive rate without sufficient context.

Access Control (3 detectors)

Missing Access Control — sensitive operations without caller validation. Scans for CALLER checks before SELFDESTRUCT, DELEGATECALL, and critical SSTORE operations. SWC-105.

Arbitrary Storage Writes — user-controlled storage slot in SSTORE. Taint analysis from CALLDATALOAD to SSTORE slot parameter. SWC-124.

Unprotected Ether Withdrawal — withdrawal functions without access checks. Identifies CALL with value without CALLER validation. SWC-105.

Dangerous Calls (4 detectors)

Unchecked External Calls — CALL return value not checked. CFG analysis verifying ISZERO check after CALL. SWC-104.

Unsafe Delegatecall — DELEGATECALL to user-controlled address or untrusted library. Taint tracking plus hardcoded address validation. SWC-112.

Unchecked Call Target — user controls target address in CALL/DELEGATECALL. Data flow from CALLDATALOAD to CALL target. The Poly Network hack (approximately $611 million, 2021) exploited this pattern.

Arbitrary Jump — user-controlled JUMP destination. Taint analysis to JUMP/JUMPI destination. SWC-127.

DeFi-Specific Critical (7 detectors)

Oracle Manipulation — price oracle usage without validation or manipulation resistance. Identifies oracle calls (Chainlink, TWAP) and checks validation patterns.

Flash Loan Attacks — contract accepts flash loans without proper protection. Bytecode scanning for flash loan provider selectors (Aave, Balancer, Uniswap V3, dYdX).

Decimal Mismatch — token operations assuming same decimals without normalization. Identifies ERC-20 calls without decimal() checks. Value calculation errors when bridging USDC (6 decimals) to DAI (18 decimals) have caused significant bridge losses.

Slippage Validation — DEX swaps without minimum output amount. Identifies swap calls with zero or missing slippage parameter.

Reward Manipulation — reward calculations vulnerable to flash loan inflation. Analyzes reward formulas for manipulation vectors (e.g., share price manipulation through donation).

Rebasing Token Issues — protocol assumes constant token balance, incompatible with rebase tokens like AMPL, stETH, and aTokens.

Fee-on-Transfer Tokens — protocol assumes received amount equals transfer amount. Identifies transfers without actual balance delta checks. Relevant to tokens like USDT, PAXG, and STA.

Proxy and Initialization (4 detectors)

UUPS Initialization — UUPS proxy without proper initialization. Checks for initialize() function and initializer modifier. Standard: EIP-1967 UUPS.

Storage Collision — proxy storage layout conflicts with implementation. Analyzes storage slot usage against EIP-1967 slots. Standards: EIP-1967, EIP-1822.

Conditional Storage Collision — storage collision under specific conditions. Symbolic execution to find collision paths.

Diamond Storage Collision — EIP-2535 Diamond facet storage conflicts. Validates diamond storage pattern compliance.

Integer and Arithmetic (3 detectors)

Unchecked Subtraction — subtraction without underflow protection. Identifies SUB operations without ISZERO checks (pre-0.8) or outside checked blocks (0.8+). SWC-101.

Division by Zero — division/modulo without zero check. Symbolic analysis of divisor with reachability checking. Applies to DIV, MOD, SDIV, and SMOD.

Incorrect Exponent — using XOR (^) instead of exponentiation (**). Pattern matching for ^ in arithmetic contexts. Common in Solidity before the ** operator.

Constructor and Deployment (3 detectors)

Incorrect Constructor — constructor with wrong name in Solidity 0.4.x. Identifies functions named like the contract but not using the constructor keyword, which makes them public. SWC-118.

EXTCODESIZE Bypass — using EXTCODESIZE for contract check, which is bypassable during construction. Identifies EXTCODESIZE checks without tx.origin validation. EXTCODESIZE returns 0 during constructor execution.

Empty Code Detection — calls to addresses without validating code exists. Identifies CALL/STATICCALL without prior EXTCODESIZE check.

High Severity — 56 Detectors

High severity vulnerabilities enable significant losses, DoS attacks, or serious protocol disruption.

Integer Arithmetic (6 detectors)

Integer Overflow — addition/multiplication without overflow checks. Version-aware: SafeMath patterns pre-0.8, unchecked blocks in 0.8+. SWC-101.

Unsafe Downcasting — type conversions without bounds validation (e.g., uint256→uint128). Silent truncation in prices, timestamps, and balances.

Sign Extension Overflow — sign extension in type conversions between signed and unsigned types. SWC-148.

Divide Before Multiply — division before multiplication causes precision loss. Data flow analysis identifying DIV→MUL sequences. Fix: always multiply first.

Tautological Compare — comparisons that are always true/false (e.g., uint x; if (x >= 0)). Constant folding and range analysis.

Write After Write — storage written twice without intervening read. Data flow analysis identifying redundant SSTORE.

MEV and Front-Running (4 detectors)

MEV Vulnerabilities — operations exploitable via transaction ordering, including price-dependent operations without protection.

Sandwich Attacks — DEX trades without slippage protection. Identifies swap operations with manipulable pricing.

Front-Running — state changes exploitable via transaction ordering. Identifies commitment schemes and state races.

Approve Race Condition — ERC-20 approve() vulnerable to front-running. Identifies approve() without increaseAllowance. SWC-114.

Randomness and Governance (4 detectors)

Weak Randomness — using block properties for randomness. Identifies BLOCKHASH, TIMESTAMP, NUMBER used as entropy source. SWC-120.

Governance Attacks — flash loan voting, delegation issues. Analyzes voting mechanisms for manipulation vectors. The Beanstalk flash loan governance attack (approximately $182 million, 2022) exploited this pattern.

veToken Governance — vote-escrowed token governance issues. Validates lock duration, voting power decay, and veToken mechanics.

Callback State Mutation — external callbacks that can modify state during execution. Identifies callback hooks that mutate state (ERC-777 hooks, ERC-1155 callbacks).

Oracle and Price Feeds (3 detectors)

TWAP Oracle Manipulation — TWAP oracle without manipulation resistance. Identifies Uniswap TWAP usage and validates window size. Observation windows under approximately 30 minutes are vulnerable to concentrated trading.

Chainlink Staleness — using Chainlink price feeds without staleness checks. Verifies updatedAt timestamp validation. SWC-adjacent.

Hash Collision — using weak hashing or truncated hashes in security contexts. SWC-133.

DoS and Resource Exhaustion (5 detectors)

Denial of Service — unbounded loops, gas griefing, forced failures. SWC-128.

Controlled Array Length — user controls array length in unbounded iteration. Taint analysis from CALLDATALOAD to loop bounds.

Calls in Loop — external calls inside loops. CFG analysis identifying CALL within loop structures. SWC-113.

Gas Griefing — attacker can cause excessive gas consumption. Identifies operations with attacker-controlled costs. SWC-126.

Memory Expansion DoS — unbounded memory allocation. Identifies MSTORE in loops or with user-controlled sizes.

Token Standards (4 detectors)

Unchecked ERC-20 — ERC-20 operations without return value checks. Identifies transfer/transferFrom without success validation. Relevant to USDT, BNB, and other non-standard tokens.

Wrapped Native Token — confusion between native ETH and WETH. Identifies simultaneous use of msg.value and WETH transfers.

Array Length Assumption — parallel arrays without length validation. Identifies array accesses without length equality checks.

Unchecked Array Bounds — array access without bounds checking.

Bridge and L2 (3 detectors)

Bridge Security — validates message verification, replay protection, and chain ID checks.

L2 Rollup Issues — validates L1↔L2 communication patterns for Optimism, Arbitrum, and zkSync.

Create2 Collision — CREATE2 salt predictability. Identifies CREATE2 with user-controlled or predictable salt.

ERC Standards (3 detectors)

Permit Vulnerabilities — ERC-2612 permit implementation issues. Validates nonce management, deadline checks, and signature verification.

Vault Inflation — ERC-4626 vault share inflation attacks. Identifies donation-based share price manipulation (first depositor attack).

Royalty Bypass — NFT royalty enforcement bypass. Validates royalty payment enforcement under EIP-2981.

Medium Severity — 25 Detectors

Medium severity issues can lead to functional problems, unexpected behavior, or create attack vectors under specific conditions.

Timestamp Dependence — block.timestamp in critical logic. Miners can manipulate timestamp by approximately 15 seconds. SWC-116.

Ether Balance Assumptions — assuming contract balance equals expected (ignores selfdestruct forced sends). SWC-132.

Signature Replay — signatures without nonce or chain ID. SWC-121.

Signature Malleability — ECDSA signatures without malleable check. Identifies ecrecover without s-value validation. SWC-117.

Signature Verification — incorrect signature validation. Validates ecrecover error handling and zero address checks. SWC-122.

ERC-1272 Signature — smart contract signature validation issues. Validates ERC-1272 implementation and fallback.

Cross-Contract Taint — tainted data from external contracts used unsafely. Inter-contract data flow analysis.

Uninitialized Storage — storage variables not initialized before read. SWC-109.

Constructor State — proxy implementation using constructor instead of initializer.

Centralization Risks — excessive admin privileges without timelock. Identifies powerful admin functions without multi-sig or timelock protection.

Missing Events — critical state changes without event emission. Identifies storage writes without LOG operations. SWC-adjacent.

Account Abstraction Issues — ERC-4337 implementation vulnerabilities. Validates UserOperation handling, signature verification, and paymaster logic.

Combo Attacks — multiple vulnerabilities that together create a novel attack vector. Cross-detector correlation and pattern matching.

Low Severity — 16 Detectors

Low severity findings identify code quality issues, best practice violations, and potential future risks.

ERC-20/721/1155 Violations — incorrect standard implementations. Validates transfer returns, approval mechanics, and callback requirements.

Deprecated Functions — using deprecated Solidity functions (CALLCODE, ORIGIN as identity, NOW). SWC-111.

Outdated Compiler — using outdated Solidity version without security fixes. SWC-102.

Floating Pragma — pragma without locked version (e.g., ^0.8.0). SWC-103.

Selfdestruct Usage — SELFDESTRUCT opcode, deprecated in post-Cancun EVM. SWC-106.

Dead Code — unreachable code paths. CFG reachability analysis. SWC-135.

Unused Variables — variables declared but never used. SWC-131.

Variable Shadowing — local variable shadows state variable. SWC-119.

Typographical Errors — common typos (= vs ==, & vs &&). SWC-129.

Default Visibility — functions without explicit visibility (pre-0.5.0). SWC-100.

Inheritance Order — incorrect multiple inheritance order. Analyzes inheritance graph for C3 linearization issues. SWC-125.

Missing Zero Address Check — address parameters without zero validation.

Assembly Analysis — inline assembly usage. Not inherently vulnerable, but requires extra review and reduces readability guarantees.

tx.origin Usage — using tx.origin for authentication. Phishing attacks via intermediary contracts. SWC-115.

Locked Ether — contract receives Ether but has no withdrawal method. SWC-132.

Private Data Exposure — storing sensitive data in “private” variables (all storage is visible on-chain). SWC-136.

Payable Fallback — payable fallback without withdrawal function. SWC-137.

Gas Optimization — inefficient gas usage patterns (storage re-reads, redundant operations, inefficient loops).

Detection Quality

Confidence Scoring

Every finding includes a confidence score (0.0–1.0) based on multiple factors:

• Pattern Match: How well the code matches known vulnerable patterns
• Semantic Validation: Whether semantic analysis confirms the pattern
• Context Analysis: Surrounding code context (e.g., detects reentrancy guards)
• Historical Correlation: Similarity to known exploits
• False Positive Rate: Detector’s historical accuracy

Confidence levels: Low (<0.5), Medium (0.5–0.7), High (0.7–0.9), VeryHigh (0.9+). For example, the reentrancy detector reduces confidence when it detects OpenZeppelin’s ReentrancyGuard.

SWC Registry Integration

36 detectors automatically populate Smart Contract Weakness Classification (SWC) references—SWC-100 through SWC-148—providing standardized vulnerability identification in reports.

Detection Technique Transparency

Every finding reports the detection technique used:

• Pattern Matching: Bytecode pattern matched against known vulnerability signatures
• Semantic Analysis: CST (e-graph) analysis confirmed structural vulnerability
• Symbolic Execution: Proved that an exploitable execution path exists
• Data Flow Analysis: Traced value propagation from source to sensitive sink
• Taint Analysis: Detected untrusted data reaching a security-critical operation
• Call Graph Analysis: Identified a vulnerable inter-procedural call chain
• Heuristic: Code characteristics suggest vulnerability based on statistical patterns

Performance Characteristics

Analysis Mode	Detector Count	Typical Time	Techniques
Fast	Pattern-based only	< 1 second	Pattern matching, e-graph CST
Standard	Full static analysis	< 10 seconds	CFG, DFA, semantic, pattern
Deep	Static + dynamic	< 5 minutes	All static + fuzzing + exploits

Detectors run in parallel across available CPU cores, each operating independently on the same intermediate representation.

A pre-computed selector-to-offset index transforms selector-based detector scans from O(n) per detector to O(1) lookups, reducing total scan complexity from O(kn) to O(n) for that class of detectors, where k is the number of selector-based detectors.

Historical Exploit Coverage

The detector suite has been validated against documented real-world exploits:

Period	Major Exploits Covered
2016	DAO, Parity Wallet
2021	Poly Network, Cream Finance, BadgerDAO
2022	Wormhole, Ronin, Nomad, Wintermute, Mango
2023	Euler, Curve Vyper, Level Finance, Platypus
2024	DMM Bitcoin, input validation attacks

Validation against real exploits is how detector accuracy is established and maintained. When a new major exploit is disclosed, the relevant detector categories are reviewed and updated to ensure the pattern is captured.

Integration with the Analysis Pipeline

Detection runs in three phases:

Phase 1 — CST Pattern Matching (<1s): E-graph constraint satisfaction using pre-compiled vulnerability rules. Identifies high-confidence pattern matches instantly.

Phase 2 — Static Analysis (<10s): Full detector suite with control flow analysis, data flow tracking, semantic analysis, and call graph construction.

Phase 3 — Dynamic Validation (<5min, deep mode only): Exploit generation for detected vulnerabilities, coverage-guided fuzzing, and concrete execution validation.

Working with Findings

Prioritize by confidence: VeryHigh (0.9+) findings are likely exploitable and should be addressed first. High (0.7–0.9) findings have strong supporting evidence. Medium (0.5–0.7) findings require context validation. Low (<0.5) findings may be false positives.

Correlate related findings: Complex vulnerabilities appear as multiple related findings. Reentrancy combined with missing access control raises overall severity. Flash loan exposure combined with oracle manipulation suggests a compound attack path.

Check context analysis: Some patterns are intentional and safe—reentrancy with explicit guards, integer operations in controlled math libraries, admin functions in properly secured contracts. The confidence breakdown’s context analysis section identifies these cases.

Use exploit generation: For critical findings in deep analysis mode, generated proof-of-concept exploits confirm exploitability and clarify attack mechanics. These are for validation purposes only.

References

1. Smart Contract Weakness Classification (SWC) Registry
2. EVM Opcodes Reference
3. EIP-1967: Standard Proxy Storage Slots
4. EIP-1822: Universal Upgradeable Proxy Standard (UUPS)
5. EIP-2535: Diamonds, Multi-Facet Proxy
6. EIP-2981: NFT Royalty Standard
7. EIP-4626: Tokenized Vault Standard
8. Grech, N. et al. “Gigahorse: Thorough, Declarative Decompilation of Smart Contracts.” ICSE 2019.