AllySec Forge

Appearance

Crypto/Blockchain Vulnerability Taxonomy — Complete Methodology Reference ​

Generated 2026-06-05 | AllySec Labs Offensive Security Research Purpose: Comprehensive catalog of every blockchain/crypto vulnerability class, attack pattern, detection method, and AI-auditability score. This document determines which attack methodology guides the AI agent builds first.

Legend ​

FieldMeaning
AI-A score1 = LLM will almost never find it; 5 = LLM finds it trivially with source code access
Exploit complexityLow (script-kiddie), Medium (competent auditor), High (specialized researcher/team)
Tool coverageWhich automated scanners/analyzers detect this class

A. Smart Contract Vulnerabilities (SWC Registry + Extended) ​

A1 — SWC-101: Integer Overflow / Underflow ​

Description: Arithmetic operation wraps around max/min value of the integer type. In Solidity <0.8.0, arithmetic was unchecked by default. Even in >=0.8.0, explicit unchecked {} blocks re-enable the behavior. Overflow in token balances allows minting tokens from nothing; underflow in subtraction drains more than available.

Real-world example: BeautyChain (BEC) — April 2018. batchTransfer overflow allowed attacker to pass a huge _value that, when multiplied by cnt, overflowed to a small number. Attacker minted 2^256 BEC tokens (~$900M paper value, ~$10M actually drained). PoC: 0x800000000000... * 2 overflowed.

Detection method: Pattern match for arithmetic in unchecked {} blocks. For older Solidity, search for +, -, * in token transfer/burn functions that lack SafeMath imports. Slither's unchecked-arithmetic detector.

Tools: Slither (detect unchecked-transfer), Mythril, Oyente, Securify, 4nalyzer. Solidity >=0.8.0 compiler also adds checks by default.

Exploit complexity: Low (pre-0.8.0), Low-Medium (post-0.8.0 with unchecked).

AI-A score: 5 — Pattern is mechanical. LLM sees a * b in an unchecked block where b is user-controlled and flags it. Very easy.

A2 — SWC-102: Outdated Compiler Version ​

Description: Contract compiled with an old Solidity version that has known bugs (e.g., optimizer bugs, ABIEncoderV2 bugs, storage corruption bugs in 0.4.x). The SWC registry tracks dozens of compiler bugs that affect deployed bytecode.

Real-world example: Solidity 0.4.22 ABIEncoderV2 bug could produce incorrect calldata encoding. Solidity 0.8.13-0.8.17 had a storage write removal bug via the optimizer (CVE-2022-29194). No single headline exploit, but preventative.

Detection method: Read pragma solidity lines. Cross-reference against the Solidity compiler bug list (soliditylang.org). Check if deployed bytecode matches source-version bytecode.

Tools: Slither (--print contract-summary shows compiler version), solc-select, truffle compile output, hardhat console.

Exploit complexity: High (most compiler bugs require deep understanding of the specific optimizer flaw). Low for reporting.

AI-A score: 5 — Trivial. LLM reads the pragma line, cross-references known-bug database, flags non-current versions.

A3 — SWC-103: Floating Pragma ​

Description: Pragma directive uses ^ (caret) to accept a range of compiler versions. A contract compiled with ^0.8.0 could be deployed with 0.8.25 today, but 0.8.26 tomorrow could introduce bugs. Non-deterministic builds make verification harder.

Real-world example: General best-practice violation. No single exploit, but the 0.4.x -> 0.5.x breaking changes and 0.5.x -> 0.8.x semantic changes have broken contracts that used floating pragmas and were recompiled.

Detection method: Regex match pragma solidity \^ in source. Slither pragma detector. Simple grep.

Tools: Slither, solhint, prettier-solidity, 4nalyzer.

Exploit complexity: N/A (hygiene/audit finding, not directly exploitable).

AI-A score: 5 — Trivial regex. LLM spots ^ in pragma lines instantly.

A4 — SWC-104: Unchecked Call Return Value ​

Description: A low-level .call(), .delegatecall(), .staticcall(), or .send() returns a boolean success value. If the return value is not checked, the caller assumes success even when the call silently fails. .send() also caps gas at 2300 which can fail silently against contracts with non-trivial fallback functions.

Real-world example: King of the Ether (2016) — unchecked send() in payout logic allowed an attacker to become king and then reject ETH payouts (by using a contract with a failing fallback), permanently blocking the game. Multiple ICO refund contracts lost funds because send() failed silently.

Detection method: Find .call( and .send( without adjacent require( or boolean assignment. Slither unchecked-lowlevel detector.

Tools: Slither, Mythril, Oyente, Securify 2.0, 4nalyzer.

Exploit complexity: Low — creating a contract that reverts in fallback blocks send/call-dependent logic.

AI-A score: 4 — Pattern is simple (call without require). False positives when return is intentionally ignored in try-catch patterns. LLMs handle this well.

A5 — SWC-105: Unprotected Ether Withdrawal ​

Description: A function that transfers ETH (via .transfer(), .send(), or .call{value:}()) is missing access controls (onlyOwner, require(msg.sender == owner)). Any external caller can drain the contract.

Real-world example: Parity Multisig Wallet #1 (July 2017) — the initWallet function could be called by anyone to reset ownership and execute drain funds. ~153K ETH stolen (~$30M at the time). This was a combination of unprotected init + delegatecall, but the core was missing access control.

Detection method: Identify functions containing transfer, send, call{value:} without onlyOwner or equivalent authorization check. Slither unprotected-function detector.

Tools: Slither, Mythril, 4nalyzer, Aderyn (Rust-based Solidity analyzer).

Exploit complexity: Low — send TX to drain, no special setup.

AI-A score: 4 — Easy for LLM: find transfer/send/call{value:} in functions lacking onlyOwner/require(msg.sender == ...). Edge cases with custom RBAC may evade.

A6 — SWC-106: Unprotected SELFDESTRUCT ​

Description: selfdestruct(address) destroys the contract and sends remaining ETH to the specified address. If callable by anyone without access control, an attacker can destroy the contract and steal all ETH.

Real-world example: Parity Wallet Library self-destruct (November 2017) — the library contract was not initialized; an attacker called initWallet to become owner, then kill() to selfdestruct it. This bricked ~587 Parity multisig wallets by destroying their shared library, freezing ~513K ETH (~$150M at the time).

Detection method: Search for selfdestruct or suicide in functions without access control.

Tools: Slither (arbitrary-send-eth, suicidal), Mythril, 4nalyzer.

Exploit complexity: Low — one TX if unprotected.

AI-A score: 5 — Trivial: find selfdestruct without access control.

A7 — SWC-107: Reentrancy ​

Description: External call made before state updates complete. The callee's fallback function re-enters the calling function, repeating the operation with stale state. Variants:

  • Single-function reentrancy: Same function re-entered.
  • Cross-function reentrancy: Re-entrant call hits a different function sharing the same state.
  • Cross-contract reentrancy: Re-entrant call hits a different contract that reads the vulnerable contract's stale state.
  • Read-only reentrancy: View/pure function reads stale state during reentrant call, poisoning off-chain oracles/views that depend on it.

Real-world example: The DAO hack (June 2016) — single-function reentrancy in splitDAO(). Attacker drained 3.6M ETH (~$50M at the time, ~$60M in extraction) leading to the ETH/ETC hard fork. Cream Finance (Oct 2021, $130M drained). SIREN protocol (Sep 2022) — read-only reentrancy affected price oracles.

Detection method: Static analysis: detect call/transfer/send before state variable writes. Symbolic execution: model re-entrant paths. Fuzzing: Echidna/Foundry property tests that simulate reentrancy. Slither's reentrancy-benign, reentrancy-eth, reentrancy-events detectors.

Tools: Slither, Mythril, Oyente, Securify 2.0, Slitherin, Echidna (fuzzing), Foundry invariant tests, Certora Prover (formal).

Exploit complexity: Low (single-function, CEI pattern violation), Medium (cross-function), High (read-only, cross-contract).

AI-A score: 3 — LLMs catch simple CEI violations well. Cross-function reentrancy across multiple files is much harder. Read-only reentrancy is subtle and often missed even by human auditors. LLMs struggle with multi-contract call flow analysis.

A8 — SWC-108: Uninitialized State Variable ​

Description: State variable declared but never assigned a value. In Solidity, uninitialized storage variables default to zero/null values. If the contract logic depends on an explicit initialization (e.g., an owner address), the contract may be exploitable until initialization.

Real-world example: Parity Multisig Wallet #2 (Nov 2017) — the library contract's _walletLibrary address was never initialized. The attacker called initMultiOwned on the deployed wallet, passing the same contract as owners, gaining control of the library. Combined with delegatecall, this froze ~$150M.

Detection method: Find state variables that lack assignment in constructor, initializer, or declaration. Slither's uninitialized-state detector.

Tools: Slither, 4nalyzer, Mythril.

Exploit complexity: Low-Medium (depends on whether the zero state is exploitable).

AI-A score: 4 — LLMs can spot uninitialized address/bool variables easily. More nuanced when the zero value is intentional (e.g., admin is address(0) until explicitly set).

A9 — SWC-109: Uninitialized Storage Pointer ​

Description: In Solidity, local variables of struct/array/mapping reference type in storage default to storage slot 0 if not explicitly initialized. Writing to them overwrites unintended storage.

Real-world example: Affected Solidity <0.5.0. The OpenZeppelin UnstructuredStorage pattern was developed partially because of this hazard. Multiple early dApps had subtle corruption from this.

Detection method: Find local variables of struct/array/mapping type lacking explicit storage/memory keyword (pre-0.5.0) or assigned storage but not pointed to an actual storage location.

Tools: Slither (uninitialized-local), solhint, Mythril.

Exploit complexity: High — requires understanding storage layout to exploit reliably.

AI-A score: 4 — Pattern recognition is straightforward. LLMs see MyStruct storage x; without subsequent x = someStorageVar; and flag it.

A10 — SWC-110: Assert Violation ​

Description: assert() is meant for invariants that should never fail. In Solidity <0.8.0, assert() consumes all gas on failure (Panic). An attacker who can trigger an assert(false) can permanently DoS a contract path. In >=0.8.0, assert uses Panic(uint256) with gas refund, but still indicates a broken invariant.

Real-world example: Multiple token contracts used assert instead of require for input validation. When the assertion failed, the user lost all gas. Not a direct theft vector but a griefing/DoS one.

Detection method: Find assert() on user-controlled inputs. Bad: assert(balance >= amount). Good: assert(address(this).balance >= totalSupply) for invariant.

Tools: Slither, solhint (rule: no-simple-vars-in-assert), 4nalyzer.

Exploit complexity: Low (DoS only, not value extraction).

AI-A score: 4 — LLMs distinguish require from assert on user-facing checks easily.

A11 — SWC-111: Deprecated Solidity Functions ​

Description: Use of deprecated keywords/constructs (throw, sha3(), suicide(), block.blockhash, now, constant for functions, var). These may have different semantics than their replacements or be removed in future compiler versions.

Real-world example: sha3() was renamed to keccak256(). throw was replaced by revert(). Several old wallets used sha3() thinking it was SHA-3 rather than Keccak-256, causing interoperability bugs.

Detection method: Regex/pattern match against known deprecated keyword list.

Tools: Slither (solc-version warnings), solhint, 4nalyzer.

Exploit complexity: Low-Medium (semantic mismatch can cause hash collisions or unexpected reverts).

AI-A score: 5 — Pure pattern match. LLM lookup of deprecated keywords is trivial.

A12 — SWC-112: Delegatecall to Untrusted Callee ​

Description: delegatecall executes code from the target contract in the context of the calling contract's storage. If the target address is user-controlled, the attacker deploys a malicious contract and passes its address, gaining full control over the caller's storage.

Real-world example: Parity Wallet Library hack (Nov 2017) — delegatecall to an uninitialized library allowed the "owner" to execute arbitrary code via the library's delegatecall. Pickle Finance (Nov 2020, $19.7M) — malicious Jar contract abusing delegatecall.

Detection method: Find delegatecall with a user-controlled address parameter. Slither's delegatecall and arbitrary-send-eth detectors.

Tools: Slither, Mythril, 4nalyzer, Aderyn.

Exploit complexity: Low — deploy malicious contract, pass address.

AI-A score: 4 — LLMs find delegatecall with user-supplied addresses easily. False positives when the address is from an immutable registry.

A13 — SWC-113: DoS with Failed Call ​

Description: External call in a loop where one failing call reverts the entire batch. An attacker can cause one recipient to be a contract that always reverts, bricking the entire distribution/withdrawal function.

Real-world example: Multiple airdrop contracts were DoS'd because one recipient address was a contract with a reverting fallback. Akutar NFT refund (2022) — 11,500 ETH locked because refund looped over recipients, some of which were contracts that reverted on receive. ~$33M frozen temporarily.

Detection method: Identify loops containing send, transfer, or call to external addresses without try/catch or pull-over-push pattern.

Tools: Slither (calls-loop), 4nalyzer, Mythril.

Exploit complexity: Low — deploy a contract that reverts on ETH receive.

AI-A score: 3 — LLMs spot the anti-pattern (push in loop). But distinguishing between correct and dangerous loop patterns requires understanding the business logic context.

A14 — SWC-114: Transaction Order Dependence / Front-running ​

Description: The transaction ordering within a block affects which actor profits. Miners/validators/searchers can reorder transactions to extract value (MEV). Two-phase commit-reveal schemes are the standard mitigation.

Real-world example: Bancor front-running (2018) — a bot watched the mempool and front-ran a large buy order, buying at low price and selling after the original order raised the price. ERC20 approve race condition — frontrunning approve(spender, N) with approve(spender, M) then transferFrom for both amounts.

Detection method: Flag functions that modify state in ways profitable when reordered (DEX swaps, auction bids, oracle updates). Slither's timestamp (block.timestamp) and manual analysis.

Tools: Slither, Mythril, Echidna (property fuzzing for MEV sensitivity), MEV-inspect, Flashbots tools.

Exploit complexity: Medium (arb bot setup), Low (basic approve frontrun).

AI-A score: 2 — Detecting TOD possibility is medium (LLM sees block.timestamp/block.number in price calc). Detecting profitable TOD and constructing the MEV strategy is hard for LLMs. Requires simulation and off-chain relay knowledge.

A15 — SWC-115: Authorization through tx.origin ​

Description: tx.origin returns the EOA that originated the transaction, not the immediate caller (msg.sender). If authorization checks use tx.origin, a phishing attack where the victim calls a malicious contract that then calls the target will pass auth.

Real-world example: Multiple phishing attacks exploiting tx.origin == owner checks. An attacker sends victim to a malicious contract; that contract calls the target's withdraw function; tx.origin is still the victim/owner, so the check passes.

Detection method: Search for tx.origin in require/if conditions. Slither tx-origin detector.

Tools: Slither, Mythril, solhint, 4nalyzer.

Exploit complexity: Low — a simple attack contract.

AI-A score: 5 — Trivial pattern: tx.origin in authorization context. LLMs flag this with near-100% recall.

A16 — SWC-116: Block Values as Proxy for Time ​

Description: Using block.timestamp for critical logic (randomness, auction deadlines, lock periods). Miners can manipulate timestamp within a ~15-second window. Using block.number for time estimates assumes constant block times which don't hold.

Real-world example: Multiple gambling/smart-contract lottery exploits where miners manipulated block.timestamp or blockhash to win. Fomo3D — the game timer used block.number, but it was not the primary exploitation vector (the airdrop was).

Detection method: Find block.timestamp used in if-conditions determining value transfer, randomness, or competitive outcomes. Slither's timestamp detector.

Tools: Slither, solhint, 4nalyzer, Mythril.

Exploit complexity: Medium (miner collusion needed for timestamp manipulation), Low if used as sole entropy source.

AI-A score: 3 — LLMs flag block.timestamp usage easily. The hard part: determining whether the ~15s manipulation margin is actually exploitable in context.

A17 — SWC-117: Signature Malleability ​

Description: ECDSA signatures in Ethereum have a symmetric s value (s and n-s both valid for the secp256k1 curve). Without restricting s to the lower half, replay attacks are possible. Also, the v parameter allows two valid recovery IDs (27/28 or 0/1).

Real-world example: OpenZeppelin's ECDSA library before v4.7.3 was vulnerable to signature malleability. Multiple NFT marketplaces (OpenSea had a bug in Wyvern) accepted malleated signatures as new orders.

Detection method: Check if ECDSA recovery uses OpenZeppelin's library (which checks s range since v4.7.3) or custom crypto that lacks require(s <= secp256k1n/2).

Tools: Slither (custom detector needed), 4nalyzer, manual review of ECDSA implementations.

Exploit complexity: Medium — requires understanding ECDSA math to construct malleated signature. Low if the library is vulnerable.

AI-A score: 3 — LLMs can check for OpenZeppelin import version and whether custom ECDSA code has s range check. But LLMs often miss subtleties of cryptographic implementations.

A18 — SWC-118: Incorrect Constructor Name ​

Description: In Solidity <0.4.22, the constructor was a function with the same name as the contract. If the contract is renamed but the constructor function name isn't updated, it becomes a regular public function callable by anyone.

Real-world example: Rubixi (2016) — the constructor was named DynamicPyramid but the contract was renamed to Rubixi. The constructor became a public function; anyone could call it to become the owner and drain funds.

Detection method: Pre-0.4.22: check if function name matches contract name. Post-0.4.22: look for functions named like the contract that aren't the constructor.

Tools: Slither, Mythril, solhint.

Exploit complexity: Low (pre-0.4.22, just call the misnamed constructor).

AI-A score: 5 — Trivial for LLM: function name == contract name in Solidity <0.4.22, not using constructor() keyword.

A19 — SWC-119: Shadowing State Variables ​

Description: A contract inherits from a parent that has state variable x, and declares its own x. In Solidity <0.6.0, this compiles but creates two separate storage slots with the same name. In >=0.6.0, the compiler warns/errors, but shadowing from inherited contracts can still be subtle.

Real-world example: Multiple token contracts where _totalSupply was shadowed in a child contract, causing the child's logic to read/write a different storage slot than the parent's totalSupply(). The parent's getter returned 0 while the child tracked a separate balance.

Detection method: Compare state variable declarations between child and inherited contracts. Slither's shadowing-state detector.

Tools: Slither, solhint, Solidity compiler >=0.6.0.

Exploit complexity: Medium — requires understanding the storage collision impact.

AI-A score: 3 — In a single file, LLMs spot name collisions. Across multiple inherited contracts spread across files, it gets harder. Diamond/EIP-2535 patterns add genuine complexity.

A20 — SWC-120: Weak Sources of Randomness ​

Description: Using on-chain values (block.timestamp, blockhash, block.difficulty, block.coinbase) as entropy. These are fully predictable by miners and visible to all nodes. Also: using keccak256 of block variables that miners control.

Real-world example: Multiple NFT mint exploits where the rarity/lottery was manipulated because the "random" index used block.timestamp or blockhash. Wolf Game (2022) — used block.timestamp + block.difficulty for random sheep/wolf assignment, exploitable by miners.

Detection method: Find keccak256 or arithmetic involving block.*, now, blockhash used as a randomness source.

Tools: Slither (weak-prng), Mythril, 4nalyzer.

Exploit complexity: Low (miner collusion or flashbot builder cooperation).

AI-A score: 3 — LLMs find block.* in entropy context. But distinguishing "acceptable for non-critical use" vs "critical vulnerability" requires context judgment.

A21 — SWC-121: Missing Signature Replay Protection ​

Description: A signed message/meta-transaction lacks replay protection (nonce, chainId, contract address, deadline). The same signature can be replayed on the same contract, across chains, or after a fork.

Real-world example: Multiple NFT marketplaces had cross-chain replay issues. Polygon/Ethereum signatures without chainId allowed replaying an order signed on Ethereum onto Polygon (and vice versa). The 2016 ETH/ETC fork allowed replaying transactions on both chains.

Detection method: Check EIP-712 typed data includes chainId, verifyingContract, and a nonce or deadline. Check that recovered signatures are invalidated after use.

Tools: Manual review primarily. Slither has no built-in detector. EIP-712 validation tools (e.g., OpenZeppelin test helpers).

Exploit complexity: Low — replay the same signed calldata.

AI-A score: 2 — Requires understanding the full meta-transaction flow, off-chain signing logic, and what fields the signature covers. LLMs miss this frequently.

A22 — SWC-122: Lack of Proper Signature Verification ​

Description: The contract uses ecrecover without checking that the returned address is not address(0) (invalid signature). Or uses a custom signature scheme that verifies the wrong message format. ecrecover returns address(0) on invalid signature, which may be a valid recipient (burn address).

Real-world example: A contract using ecrecover without require(signer != address(0)) where address(0) was an admin — invalid signatures authenticated as admin. Multiple DeFi governance contracts where ecrecover zero-check was missing.

Detection method: Find ecrecover calls missing the zero-address check. Find custom signature verification code that deviates from EIP-712 standard.

Tools: Slither (custom detectors exist), 4nalyzer, Solidity compiler warnings.

Exploit complexity: Low-Medium.

AI-A score: 3 — LLMs spot missing address(0) check on ecrecover return value. Harder when the verification logic is spread across multiple functions/libraries.

A23 — SWC-123: Requirement Violation ​

Description: Using require() with a condition that is always true, or always false, due to a logic error. An always-false require permanently DoS's a function. An always-true require provides no protection.

Real-world example: An assert(1 == 2) or require(foo == foo) from a typo. Less common as exploits, more common as logic bugs that prevent function execution.

Detection method: Slither's tautology analysis. Manual review of complex conditions.

Tools: Slither (tautology), solhint.

Exploit complexity: N/A (it's a dead path or always-pass).

AI-A score: 3 — Trivial tautologies (x == x) are easy. Complex tautologies across variable aliasing are harder.

A24 — SWC-124: Write to Arbitrary Storage Location ​

Description: A function writes to a storage slot computed from user input. Equivalent to an arbitrary write primitive. Can overwrite owner, implementation address, balances, etc.

Real-world example: Delegatecall with user-controlled target (as above) gives arbitrary storage write. Diamond pattern facets with unvalidated selectors. Array index out-of-bounds in older Solidity versions.

Detection method: Track storage writes where the slot index or struct member is user-influenced. Slither's arbitrary-send-eth (related).

Tools: Slither, Mythril (symbolic execution finds reachable storage corruption).

Exploit complexity: Medium-High (need to identify which slot to overwrite for maximal impact).

AI-A score: 2 — LLMs struggle with data-flow analysis that traces user input to storage write targets across multiple intermediate variables.

A25 — SWC-125: Incorrect Inheritance Order ​

Description: Solidity uses C3 linearization for multiple inheritance. Methods in more-derived contracts override those in more-base contracts. If the inheritance order is wrong, a parent's method may be called instead of the intended child's, or a modifier from the wrong contract applies.

Real-world example: A contract with contract A is B, C where both B and C override the same function, and B is intended to take precedence but C3 linearization gives priority to C. The wrong implementation runs. Common in complex upgrade proxy patterns.

Detection method: Run solc with inheritance graph output. Compare against expected override order.

Tools: Slither (shadowing-local, inheritance graph printer), solhint, Remix inheritance graph.

Exploit complexity: Low (if known), High (to discover).

AI-A score: 2 — LLMs don't execute the linearization algorithm mentally. They can describe the C3 rules but won't reliably detect when the order is wrong for a specific intent.

A26 — SWC-126: Insufficient Gas Griefing ​

Description: An attacker provides just enough gas for the external call but not enough for the subsequent logic. After the external call succeeds, the transaction reverts on the post-call logic due to out-of-gas. The attacker gets a state change in the external call without the follow-up logic.

Real-world example: Relayers that refund gas after an operation — attacker provides exact gas for the operation but not the refund logic, getting the service without paying gas. Mostly a relay/minor concern.

Detection method: Identify patterns where external calls are followed by critical state changes without gas accounting.

Tools: Manual review; not well-covered by automated tools.

Exploit complexity: Medium — requires careful gas calculation.

AI-A score: 1 — Very hard for LLMs. Requires gas-level reasoning, understanding EIP-150 63/64 rule, and the specific gas costs of each opcode in the post-call path.

A27 — SWC-127: Arbitrary Jump with Function Type Variable ​

Description: In Solidity <0.5.0, assembly jump instructions could be manipulated via function type variables stored in storage. An attacker could overwrite the function pointer to redirect execution to an arbitrary code location.

Real-world example: Primarily academic; no headline exploits. The Solidity compiler removed this capability.

Detection method: Check for assembly blocks using jump with storage-loaded variables. Only relevant pre-0.5.0.

Tools: Slither (assembly analysis), Mythril.

Exploit complexity: High — requires EVM bytecode-level understanding.

AI-A score: 1 — Requires bytecode + storage layout analysis that's beyond LLM source-code audit capability without specialized tool integration.

A28 — SWC-128: DoS With Block Gas Limit ​

Description: A function iterates over an unbounded array or performs operations whose gas cost grows with array size. If the array grows beyond the block gas limit, the function becomes permanently unexecutable (bricked).

Real-world example: Governance voting systems that iterate over all voters to tally. Airdrop claim functions that loop over all recipients. Multiple contracts had to be abandoned when arrays grew too large. The GovernMental 1500 ETH jackpot (2016) — the payout loop exceeded gas limit as creditors grew.

Detection method: Identify unbounded for/while loops over storage arrays that can grow. Slither costly-loop detector.

Tools: Slither, 4nalyzer, Mythril, gas reporters (hardhat-gas-reporter, foundry gas snapshots).

Exploit complexity: Low — just call functions that append to the array until it's too large.

AI-A score: 4 — LLMs spot unbounded array iteration easily. The question is whether the array can grow in practice; LLMs can reason about this from the codebase.

A29 — SWC-129: Typographical Errors ​

Description: Operator typos: == vs =, += vs =+, < vs. >, && vs ||, incorrect variable name. In Solidity <0.5.0, = in conditions is allowed (assignment returns the assigned value).

Real-world example: The Firo/Zcoin Zerocoin bug (2017) — a single typo (== instead of =) in the spend validation allowed double-spending. Attacker minted 370K fake XZC (~$440K at the time). Operator typos are the oldest smart contract bug class.

Detection method: Solidity compiler >=0.5.0 disallows assignment in conditions by default. Pattern match for =+ (should be +=). Contextual analysis of operators.

Tools: solhint, Solidity compiler warnings, Slither, 4nalyzer.

Exploit complexity: Low-Medium (depends on the semantic impact of the typo).

AI-A score: 2 — LLMs struggle with typos because they "read" the intended meaning. a =+ b is read as a += b by an LLM unless specifically directed to look for typos. The Firo typo (== where = should be) is the type of thing LLMs miss in code review.

A30 — SWC-130: Right-To-Left-Override (RTLO) Control Character ​

Description: Unicode RTLO character (U+202E) in source code reverses the display order of text. What appears as require(balance - amount >= 0) could actually be require(balance - amount 0 >= ) with the check on a different variable.

Real-world example: Largely theoretical for Solidity (compilers reject it). The 2021 Rust/Cargo supply chain attack used RTLO in source code to hide malicious imports. More relevant for JavaScript/TypeScript front-ends and tooling.

Detection method: Scan source files for Unicode bidirectional control characters.

Tools: CI/CD linters checking for non-ASCII in Solidity files. GitHub now flags these.

Exploit complexity: Medium (requires getting malicious code past review).

AI-A score: 1 — LLMs render text, not bytes. They cannot see RTLO characters by design. This requires a byte-level scanner.

A31 — SWC-131: Presence of Unused Variables ​

Description: Variables declared but never read. Can indicate incomplete implementation, dead code, or a bug where the wrong variable is used elsewhere (shadowing, typo in variable name).

Real-world example: Audit finding in many protocols. Unused uint256 _deadline parameter in a swap function that was supposed to check transaction expiration but forgot the check.

Detection method: Compiler warnings, Slither's unused-state and unused-return detectors.

Tools: Slither, Solidity compiler, solhint, 4nalyzer.

Exploit complexity: N/A (code quality finding).

AI-A score: 5 — Trivial. LLMs flag unused variables consistently.

A32 — SWC-132: Unexpected Ether Balance ​

Description: A contract's ETH balance can be increased via selfdestruct(address), coinbase rewards to the contract's address, or pre-funded at deployment. Contracts that rely on address(this).balance for accounting (e.g., "total deposits == contract balance") can be manipulated.

Real-world example: Force-feeding ETH via selfdestruct to a contract that uses address(this).balance as a denominator for share calculation. The attacker inflates the balance, breaking the share math.

Detection method: Identify contracts where address(this).balance is used in accounting logic without considering forced ETH. Slither's incorrect-balance detector.

Tools: Slither, manual review.

Exploit complexity: Low — selfdestruct a contract with the target as beneficiary.

AI-A score: 3 — LLMs understand "can't prevent ETH from being sent" but may not trace the accounting impact of inflated address(this).balance through complex share calculations.

A33 — SWC-133: Hash Collisions with Multiple Variable-Length Arguments ​

Description: abi.encodePacked(a, b) where a and b are dynamic types (bytes, string) produces ambiguous encoding: abi.encodePacked("ab", "c") == abi.encodePacked("a", "bc"). Using such hashes for signatures or uniqueness checks allows hash collisions.

Real-world example: OpenZeppelin's AccessControl preview used abi.encodePacked for role hashes. Multiple NFT marketplaces hashed concatenated strings with abi.encodePacked for order IDs, allowing order collision attacks.

Detection method: Find keccak256(abi.encodePacked(...)) with multiple dynamic types. Should use abi.encode() or fixed-width types.

Tools: Slither (encode-packed-collision), solhint, 4nalyzer.

Exploit complexity: Medium — construct colliding inputs.

AI-A score: 4 — Simple rule: abi.encodePacked with multiple dynamic types in hash context. LLMs catch this reliably.

A34 — SWC-134: Message Call with Hardcoded Gas Amount ​

Description: Using .transfer() (2300 gas) or .send() (2300 gas) or hardcoded gas in .call{gas: 50000}(). Gas costs change with EVM upgrades (EIP-1884, EIP-2929, EIP-3529). 2300 gas may not be enough for a contract's fallback function. Hardcoding gas can break forward compatibility.

Real-world example: After EIP-1884 increased the gas cost of SLOAD from 200 to 800, many contracts using .transfer() broke because the receiving contract's fallback could no longer read a single storage slot within 2300 gas.

Detection method: Find .transfer(), .send(), .call{gas: <literal>}().

Tools: Slither, solhint.

Exploit complexity: Low — hardcoded gas is an audit finding, not typically a direct exploitation vector.

AI-A score: 5 — Trivial: find hardcoded gas literals.

A35 — SWC-135: Code With No Effects / Dead Code ​

Description: Functions or code blocks that execute but produce no state change and return no value. Could be a bug (missing assignment, wrong variable) or a vestigial function.

Real-world example: Audit finding in many protocols. Common pattern: owner = newOwner; (assignment) vs owner == newOwner; (comparison, no effect). The latter silently does nothing.

Detection method: Slither's dead-code detector, compiler warnings for unused variables.

Tools: Slither, solhint, Solidity compiler.

Exploit complexity: N/A (or Low if the dead code masks a missing operation).

AI-A score: 4 — LLMs are good at spotting x == y; as a standalone statement that does nothing.

A36 — SWC-136: Unencrypted Private Data On-Chain ​

Description: Storing secrets (passwords, API keys, private keys, PII) in contract storage. All on-chain data is publicly readable. private visibility only restricts other contracts, not off-chain readers.

Real-world example: Multiple DeFi projects accidentally deployed with test private keys in source code that got stored on-chain. A gambling contract that stored player "secret" numbers on-chain where everyone could read them before revealing.

Detection method: Look for string literals resembling keys, passwords, tokens in contract storage.

Tools: Slither (unencrypted-private-data), manual review, TruffleHog for source repos.

Exploit complexity: Low — just read storage slots with eth_getStorageAt.

AI-A score: 3 — LLMs can spot obvious secrets (private keys, API keys) but struggle with PII or less obvious sensitive data patterns.

A37 — Flash Loan Attacks ​

Description: Flash loans (uncollateralized borrow, use, repay in one block) are legitimate but enable capital-efficient attacks. Combined with price oracle manipulation, governance manipulation, or collateral ratio exploits. The loan provides the "ammo" without requiring the attacker to hold capital.

Real-world example: bZx (Feb 2020, $1M) — flash loan + Uniswap price manipulation to drain bZx lending pool. Cream Finance (Oct 2021, $130M) — flash loan + yUSD price manipulation. Euler Finance (Mar 2023, $197M) — flash loan + donation attack. Mango Markets (Oct 2022, $114M) — flash loan + oracle manipulation + governance attack.

Detection method: Model lending pools and check if any external call can influence internal price calculations within the same transaction. Simulation testing.

Tools: Echidna (invariant testing), Foundry (stateful fuzzing), Chaos Labs/ChaosLabs risk simulations, Certora Prover. No silver-bullet static tool.

Exploit complexity: High (requires composing multiple DeFi primitives).

AI-A score: 1 — Flash loan attacks are multi-contract compositions that LLMs cannot reason about from single-contract source. Requires cross-protocol simulation and economic modeling.

A38 — Oracle Manipulation ​

Description: Manipulating the price feed that a DeFi protocol depends on. Variants:

  • Spot price from DEX pool: Swap large amount to skew Uniswap/Balancer spot price, then use the manipulated price for liquidation/borrowing in the target protocol.
  • TWAP manipulation: Flash-loan capital to sustain a manipulated price for long enough to move a TWAP oracle.
  • Stale prices: Oracle hasn't been updated (Chainlink heartbeat missed, chronicle not pushed). Protocol uses old price.
  • Centralized oracle compromise: Compromised Chainlink node operators, Pyth validator collusion.

Real-world example: Venus Protocol (2021, $200M) — manipulated XVS price via thin-liquidity pool, borrowed against inflated collateral. Inverse Finance (Apr 2022, $15.6M) — manipulated INV price via TWAP on low-liquidity pool. Mango Markets (Oct 2022, $114M) — manipulated MNGO price.

Detection method: Trace price source dependency. If spot AMM price, flag as high risk. If Chainlink with heartbeat monitoring, lower risk. If custom TWAP on low-liquidity pool, flag.

Tools: Slither (oracle-manipulation custom detectors exist), Echidna, Foundry invariant tests, Tenderly simulations.

Exploit complexity: Medium-High (depends on oracle liquidity depth).

AI-A score: 2 — LLMs can identify the oracle source (Uniswap pool, Chainlink aggregator). But determining whether the oracle is manipulable requires liquidity data and economic analysis LLMs can't do from source alone.

A39 — Governance Attacks ​

Description: Variety of attack vectors on DAO governance:

  • Proposal flooding: Submit many proposals to exhaust voter attention.
  • Flash-loan voting: Borrow governance tokens for the duration of the vote snapshot, vote maliciously, return tokens.
  • Vote buying: bribe pools (e.g., Hidden Hand, Votemak) where attackers pay voters to support malicious proposals.
  • Timelock bypass: Governance has no timelock or timelock too short for users to react.
  • Malicious proposal: Proposal upgrades proxy to malicious implementation.

Real-world example: Beanstalk Farms (Apr 2022, $182M) — flash-loan governance attack. Attacker borrowed $1B in stablecoins, converted to BEAN3CRV LP to get governance power, passed emergency proposal draining all funds. Tornado Cash governance takeover (May 2023) — attacker passed malicious proposal adding fake logic, stole ~$1M.

Detection method: Check if governance power is based on a liquid token (flash-loanable). Check timelock duration. Check proposal quorum thresholds.

Tools: Manual review, OpenZeppelin Defender governance monitoring, Tally analysis. No static analysis tool covers this well.

Exploit complexity: High (requires large capital even if flash-loaned, complex execution).

AI-A score: 1 — Requires understanding governance token liquidity, off-chain social dynamics, and economic incentives. Way beyond source code audit.

A40 — MEV Exploits ​

Description: Maximal Extractable Value attacks utilizing transaction ordering:

  • Sandwich attacks: Front-run + victim TX + back-run around a DEX swap.
  • Arbitrage: Extract profit from price differences between pools.
  • Liquidation frontrunning: Copy profitable liquidation TX from mempool with higher gas.
  • Uncle bandit attacks: Mine uncles that include TX that would have been reorganized.

Real-world example: $675M+ extracted via MEV on Ethereum since 2020. Individual sandwiches can extract 0.5-5% of the victim's swap. The largest single MEV extraction was ~$3.6M in one block.

Detection method: Check if protocol has slippage protection, deadline parameters, commit-reveal schemes. Test with MEV simulation tools.

Tools: MEV-inspect, Flashbots tools, EigenPhi, Tenderly, Foundry (mev testing).

Exploit complexity: Medium (requires running a searcher bot). Low for front-running unapproved allowance changes.

AI-A score: 1 — MEV requires off-chain infrastructure, mempool monitoring, and gas auction strategy. No source-code-only analysis catches it.

A41 — Access Control Misconfigurations ​

Description: Missing or misconfigured access control:

  • Missing onlyOwner on critical functions.
  • Ownable not initialized (owner is address(0)).
  • Using onlyRole but role admin is unset or role is unassigned.
  • Ownable.transferOwnership two-step missing (can transfer to wrong address).
  • renounceOwnership() left callable, bricking the contract.

Real-world example: Multiple NFT projects where renounceOwnership() was called accidentally or by an attacker, permanently bricking contract administration. Wormhole exploit (Feb 2022, $326M) partly involved access control on the Solana side.

Detection method: Build access control graph from modifiers/requires. Check critical functions (withdraw, mint, upgrade, pause) are protected.

Tools: Slither (unprotected-function, incorrect-ownership-transfer), 4nalyzer, Aderyn.

Exploit complexity: Low — just call the unprotected function.

AI-A score: 4 — LLMs trace onlyOwner/onlyRole through the contract tree well. Two-step transfer and renounceOwnership checks are straightforward.

A42 — Upgrade Proxy Bugs ​

Description: UUPS, Transparent, or Beacon proxy patterns with implementation vulnerabilities:

  • Storage collision: New implementation uses different storage layout, corrupting data.
  • Uninitialized implementation: The implementation contract can be initialized by anyone.
  • UUPS upgradeTo unprotected: Anyone can upgrade to malicious implementation.
  • Transparent proxy selector clash: Function selectors in proxy and implementation collide.
  • Beacon misconfiguration: Beacon points to malicious implementation.

Real-world example: Wormhole (Feb 2022, $326M) — the Solana-side guardian set update was not properly validated. Audius (Jul 2022, $6M) — storage collision in governance upgrade allowed attacker to pass malicious proposal. Multiple UUPS contracts where implementation was left uninitialized and attacker called initialize() to become owner.

Detection method: Check storage gap reserves. Verify initializer is protected (initializer modifier or _disableInitializers() in constructor). Verify upgradeTo has access control. Compare storage layouts between versions.

Tools: Slither (uninitialized-implementation, storage-collision), OpenZeppelin Upgrades plugin (hardhat-upgrades, foundry-upgrades), solc storage layout diff.

Exploit complexity: Medium (UUPS unprotected upgrade), Medium (uninitialized implementation).

AI-A score: 3 — LLMs check for initializer modifier, _disableInitializers() in constructor, upgradeTo auth. Storage layout analysis across versions is harder for LLMs without tooling.

A43 — Cross-Chain Bridge Attacks ​

Description: Bridges lock/burn assets on chain A and mint/release on chain B. Attack vectors:

  • Fake deposit events: Attacker generates a valid-looking deposit event on chain A without actually depositing, gets free mint on chain B.
  • Validator takeover: Compromise the bridge's validator/relayer set (requires 2/3 or supermajority).
  • Message verification bypass: Bug in the light client or merkle proof verification on the destination chain.
  • Replay across chains: Same deposit event replayed on another destination chain.

Real-world example: Wormhole (Feb 2022, $326M) — attacker forged a valid guardian signature for a fake deposit. Ronin Bridge (Mar 2022, $624M) — 5 of 9 validators compromised (4 Ronin + 1 Axie DAO). Nomad Bridge (Aug 2022, $190M) — message verification bug accepted any unverified message root. BSC Token Hub bridge (Oct 2022, $570M) — forged merkle proof. Poly Network (Aug 2021, $611M) — contract call bypass.

Detection method: Verify that deposit events are validated by sufficient validator signatures. Check merkle proof verification logic. Check relay/validator set is decentralized. Simulate attack with foundry fork tests.

Tools: Manual review + formal verification (Certora, K-framework), Echidna, Foundry fuzz testing.

Exploit complexity: High (requires deep understanding of cross-chain messaging and validator sets).

AI-A score: 1 — Cross-chain bridges involve multiple runtimes, validator sets, and cryptographic proof systems. Way beyond single-contract LLM audit capability.

A44 — Read-Only Reentrancy ​

Description: A view/pure function reads state that is temporarily inconsistent due to an ongoing reentrant call. An attacker re-enters a contract mid-execution and calls a "read-only" function whose return value is used by an off-chain system or another on-chain contract's oracle mechanism.

Real-world example: SIREN Protocol (Sep 2022, $3.5M) — read-only reentrancy via Curve pool. The Curve pool's get_virtual_price() was called mid-reentrancy, returning a stale/lower price which SIREN used to price options incorrectly. Sentinel Protocol, DEUS Finance, and Omni Protocol also had read-only reentrancy issues.

Detection method: Identify external calls followed by state reads in functions marked view/pure that are used in critical calculations. Enhanced Slither detectors.

Tools: Slither's reentrancy-events (partial), Certora, Echidna, specialized detectors.

Exploit complexity: High — requires identifying which view function reads stale state and how that affects downstream logic.

AI-A score: 1 — Extremely subtle. LLMs rarely catch that a view function called from outside the reentrant context sees inconsistent state. Requires deep cross-contract data-flow reasoning.

A45 — Precision Loss / Rounding Errors ​

Description: Solidity does not support floating-point math. Integer division truncates toward zero. Multiplication before division vs. division before multiplication order affects precision. Fee and share calculations that round in the user's favor can drain value over many transactions.

Real-world example: Multiple lending protocols where rounding errors in exchange rate calculations allowed depositors to extract small amounts. Yearn vaults — the "first depositor attack" (see vault share inflation) is a precision loss variant. Compound-like protocols where exchangeRate = totalCash / totalSupply rounded down, allowing repeated deposit/withdraw cycles to steal.

Detection method: Identify division operations where the numerator is smaller than the denominator (rounds to zero). Check if fee-on-transfer tokens break amount * fee / FEE_DENOM. Check for x * y / z vs x / z * y ordering.

Tools: Slither (divide-before-multiply), Echidna (property fuzzing for precision), Foundry invariant tests, Certora.

Exploit complexity: Medium — requires many transactions to extract significant value.

AI-A score: 2 — LLMs can flag "division before multiplication" patterns. But determining whether rounding errors are exploitable requires understanding acceptable loss bounds and exchange rate dynamics.

A46 — Infinite Mint Bugs ​

Description: Mint function lacks authorization or has logic flaw allowing unlimited token creation. Variants:

  • Unprotected mint().
  • Mint-on-fee where fee recipient is attacker-controlled.
  • Reward calculation overflows allowing massive reward mint.
  • LP token mint without underlying deposit (synthetic inflation).

Real-world example: Cover Protocol (Dec 2020, $3M) — infinite mint via burn() returning COVER + yield. Paid Network (Mar 2021, $180M) — attacker minted 59M PAID tokens via unprotected mint function and dumped them. Qubit Finance (Jan 2022, $80M) — logical bug in deposit allowed minting xETH without depositing ETH.

Detection method: Identify _mint() calls. Trace authorization path. Check if mint amount is bounded. Slither's unprotected-function for mint.

Tools: Slither, 4nalyzer, Aderyn, Echidna (invariant: totalSupply only increases through authorized paths).

Exploit complexity: Low-Medium (depends on what authorization is missing).

AI-A score: 4 — LLMs trace mint authorization well. Unprotected mint functions are obvious. Logic bugs in mint calculation are harder.

A47 — Fee-on-Transfer Token Incompatibility ​

Description: Some ERC20 tokens take a fee on transfer (e.g., USDT can do this, STA, PAXG). If a protocol uses transferFrom and assumes the full amount is received, the actual received amount is less. This breaks internal accounting. Also: rebasing tokens (stETH, aToken) and tokens with transfer hooks.

Real-world example: Multiple DeFi protocols broke when interacting with USDT (which deducts fee in some circumstances). Balancer V1 pools with fee-on-transfer tokens had incorrect balance tracking causing pool insolvency.

Detection method: Check if protocol measures actual balance before/after transfer instead of assuming amount. Check if safeTransferFrom wrappers validate received amount.

Tools: Slither (custom detectors), Echidna, Foundry fork tests with token mocks.

Exploit complexity: Medium — requires finding a protocol that both handles fee-on-transfer tokens and makes incorrect balance assumptions.

AI-A score: 2 — LLMs see transferFrom(amount) but can't know if the token takes a fee without analyzing the token contract or knowing token-specific behavior. Cross-contract + off-chain knowledge.

A48 — ERC-777 / Token Hook Reentrancy ​

Description: ERC-777 tokens call tokensToSend() and tokensReceived() hooks on sender/receiver. These hooks execute before the token contract updates its internal balances, creating a reentrancy vector from the token level upward into the calling contract.

Real-world example: imBTC Uniswap V1 exploit (Apr 2020, $300K) — imBTC was an ERC-777 token; the tokensToSend hook allowed re-entering Uniswap during a swap, exploiting the pre-balance-update state. Lendf.me (Apr 2020, $25M) — same ERC-777 reentrancy vector, attacker drained dForce lending pool.

Detection method: Check if protocol interacts with arbitrary tokens (via token parameter) rather than whitelisted tokens. Check for CEI violations that include token transfers.

Tools: Slither (reentrancy-eth, reentrancy-advanced), Echidna with ERC-777 mock.

Exploit complexity: Low-Medium — deploy an ERC-777 token with malicious hooks.

AI-A score: 2 — LLMs understand the concept but detecting it requires knowing whether arbitrary tokens can be passed and whether CEI pattern is violated around token transfers.

A49 — Permit Signature Phishing ​

Description: EIP-2612 permit() allows gasless token approvals via signatures. Attackers trick users into signing a permit that grants token spending approval to an attacker address. The signature is submitted on-chain without the user sending a transaction. Users may not realize they authorized spending.

Real-world example: Widespread phishing campaigns (2022-2024) where fake dApp frontends prompt users to sign permit() messages that drain their wallets. Not a smart-contract bug per se, but a design pattern that weakens user security.

Detection method: Not a contract vulnerability — it's a UX/phishing issue. Auditors note that protocols using permit should implement UI safeguards.

Tools: Wallet-level simulation (Wallet Guard, Pocket Universe, Fire). Not a static analysis concern.

Exploit complexity: Low — send phishing link, get signature, submit.

AI-A score: 1 — Not detectable from contract source code. This is a frontend/phishing attack vector.

B. Protocol/Consensus Layer Vulnerabilities ​

B1 — Long-Range Attacks (Proof of Stake) ​

Description: In PoS systems, validators can create an alternative chain history starting from a point where they held stake, producing blocks faster than the main chain. Since they're not slashed on the alternate chain, there's no cost. Mitigated by "weak subjectivity" checkpoints, but new nodes syncing from genesis are vulnerable.

Real-world example: Theoretical; no successful long-range attack on a major PoS chain. Cosmos/Ethereum have checkpointing to prevent this. Several smaller PoS chains without checkpointing are theoretically vulnerable.

Detection method: Audit the fork-choice rule. Check if the protocol has finalized checkpoints that new nodes bootstrap from. Verify that "nothing-at-stake" is addressed.

Tools: Protocol-level formal verification (TLA+, Quint, Ivy). Model checking.

Exploit complexity: High — requires controlling historical validator keys (which may be available cheaply).

AI-A score: 1 — Requires understanding distributed consensus protocols, fork-choice rules, and game theory. Not an LLM source-code audit task.

B2 — Nothing at Stake ​

Description: In naive PoS, validators can vote on multiple conflicting forks at no cost. Their stake is "slashed" on one fork but they keep it on the other. Without slashing conditions, there's no disincentive to equivocate. Ethereum's Casper FFG uses slashing conditions to solve this.

Real-world example: Pre-Ethereum 2.0 PoS chains that lacked slashing conditions were theoretically vulnerable. No major exploit because attackers couldn't finalize conflicting checkpoints on both forks.

Detection method: Verify that the protocol has slashing conditions for equivocation. Check that validators are penalized for signing conflicting attestations.

Tools: Protocol simulation, formal verification.

Exploit complexity: High — requires running validators on multiple forks.

AI-A score: 1 — Consensus protocol design analysis, far beyond source code audit.

B3 — Eclipse Attacks ​

Description: An attacker monopolizes a victim node's P2P connections (all outbound and inbound slots), isolating it from the honest network. The victim sees only attacker-controlled blocks, enabling double-spends, 51% attacks with less hashpower, or transaction censorship.

Real-world example: Bitcoin — academic demonstration (Heilman et al., 2015) showed eclipse attacks on Bitcoin nodes by filling all 117 incoming connection slots. Ethereum — eclipse attacks demonstrated on Geth nodes pre-v1.8 (fixed by EIP-1459 node table changes, changing the peer selection algorithm).

Detection method: Check P2P connection slot allocation. Check if node discovery is permissionless. Check if IP address selection is deterministic (predictable bucket selection).

Tools: Protocol-specific test frameworks, network simulation, Bitcoin/Ethereum devp2p test suites.

Exploit complexity: High — requires infrastructure to fill all connection slots, often BGP manipulation or botnet.

AI-A score: 1 — P2P networking code with connection management and peer discovery. LLMs lack the network-level simulation capability needed.

B4 — Erebus Attacks (BGP Hijacking of P2P) ​

Description: Attacker hijacks BGP routes to intercept P2P traffic at the ISP level, partitioning the network without touching the blockchain protocol itself. A subset of eclipse attacks executed at the routing layer.

Real-world example: Academic concept (Tran et al., IEEE S&P 2020, "Erebus Attack"). Demonstrated feasible against Bitcoin and Ethereum P2P networks with a modest BGP prefix hijack. No known wild exploitation (would require ISP-level access or BGP hijacking capability).

Detection method: Not detectable from blockchain source code — requires BGP monitoring and decentralized peer discovery over multiple network paths.

Tools: BGP monitoring (BGPStream, RIPE RIS), P2P network monitoring.

Exploit complexity: Very High — requires BGP hijacking capability (nation-state level).

AI-A score: 1 — Network infrastructure attack, not a code vulnerability.

B5 — Timejacking ​

Description: Attacker manipulates a node's system time via NTP attacks or falsified block timestamps, causing the node to reject valid blocks or accept invalid ones. The node's time is critical for block validation (median time past, future block rejection).

Real-world example: Academic demonstration. Bitcoin nodes reject blocks with timestamps >2 hours in the future and < median of past 11 blocks. A timejacked node could be tricked into accepting a low-difficulty chain.

Detection method: Check time-handling code for reliance on system time vs. network-adjusted time. Verify NTP security.

Tools: Manual review of consensus time-handling code.

Exploit complexity: Medium — requires NTP spoofing or MITM.

AI-A score: 1 — Requires understanding time-keeping in distributed systems and NTP. Not a standard code audit.

B6 — Balance Attacks ​

Description: Attacker equivocates (signs blocks at the same height on different forks) to delay consensus while having only a minority of total stake. The attacker communicates with different subgroups of validators, causing them to build on different forks.

Real-world example: Academic concept (Natoli & Gramoli, 2017). Applied to Ethereum's GHOST protocol. No known in-the-wild exploitation.

Detection method: Check the fork-choice rule for robustness against equivocating validators. Verify slashing conditions disincentivize equivocation.

Tools: Formal verification of fork-choice rule.

Exploit complexity: High — requires precise network timing and validator subset control.

AI-A score: 1 — Consensus protocol analysis, not code audit.

B7 — Finality Reversion ​

Description: A finalized block is reverted due to a consensus bug. In Ethereum, this requires 1/3 of validators to be slashed (inactivity leak) or a client bug that causes the chain to follow an invalid finality.

Real-world example: Ethereum Beacon Chain experienced a 7-block reorg in May 2022 due to a Proposer Boost issue (non-finality reversion, not finalized block reversion). A finality reversion has not occurred on Ethereum mainnet. Several smaller Cosmos chains experienced finality halts.

Detection method: Check consensus client implementation for edge cases in justification/finalization logic. Fork choice test vectors.

Tools: Client test suites (ethereum/tests, EF test vectors), Hive (Ethereum), simulation frameworks (Kurtosis).

Exploit complexity: Very High — requires consensus bug in a major client.

AI-A score: 1 — Consensus implementation auditing requires formal methods and test vector execution, not LLM analysis.

B8 — Empty Block Mining ​

Description: Miners/validators propose empty blocks to avoid the computational cost of executing transactions while still collecting block rewards and MEV. This reduces network throughput. In PBS (Proposer-Builder Separation), proposers may accept empty blocks from non-competitive builders.

Real-world example: On Ethereum, empty blocks are regularly produced (1-2% of blocks). Not an exploit per se, but a network efficiency concern. Some MEV-Boost blocks were empty because the builder failed to deliver.

Detection method: Monitor block fullness metrics. Check if protocol penalizes empty blocks.

Tools: Block explorers, dune analytics, mevboost.pics.

Exploit complexity: N/A — it's protocol rent extraction, not a bug.

AI-A score: 1 — Protocol-level economic analysis, not code audit.

B9 — Uncle Bandit / Nephew Exploitation ​

Description: Miners strategically include or exclude uncle blocks to maximize rewards. "Uncle Bandit" attacks involve mining uncles of blocks that would be reorganized. "Nephew" attacks reference the block that includes an uncle. In Ethereum PoS, this has been replaced by the proposer/attester reward structure.

Real-world example: Ethereum PoW era (pre-Merge). Flashbots research demonstrated that miners could increase revenue by ~5-7% via strategic uncle inclusion. Mostly an academic concern.

Detection method: Analyze block reward structure. Check uncle inclusion rewards.

Tools: MEV-inspect, Flashbots tools.

Exploit complexity: Medium — requires mining infrastructure.

AI-A score: 1 — Game theory and protocol economics, not code vulnerability.

B10 — MEV-Boost / PBS Vulnerabilities ​

Description: Proposer-Builder Separation (PBS) delegates block construction to specialized builders. Vulnerabilities:

  • Builder censorship: Builder excludes certain transactions.
  • Relay trust: The relay can see bundle contents and could front-run.
  • Proposer equivocation: Proposer reveals block to multiple builders, plays them against each other.
  • Timing games: Builders delay block release to extract more MEV.

Real-world example: Ethereum MEV-Boost relay centralization (5 relays process >90% of blocks). Relay failures caused missed slots (April 2023). Unbundling attacks demonstrated where builders can decompose searcher bundles to steal MEV.

Detection method: Audit relay code for data leakage. Check builder commitment schemes. Verify proposer cannot equivocate.

Tools: Flashbots relay audit tools, protocol simulation.

Exploit complexity: High — requires operating as a builder or relay.

AI-A score: 1 — Requires understanding PBS protocol, relay infrastructure, and trust model.

B11 — Validator Selection Bias / RANDAO Manipulation ​

Description: RANDAO is Ethereum's randomness source for validator/proposer selection. The last validator to reveal their RANDAO commitment can bias the output by choosing to reveal or withhold (at the cost of being slashed). In practice, the bias is one bit.

Real-world example: No production exploit — the one-bit bias is not sufficient for profitable manipulation given slashing penalties. Academic concern: with cheaper stake or no slashing, RANDAO bias could influence proposer selection.

Detection method: Audit randomness generation. Check commitment scheme properties. Verify bias is bounded and slashing penalty exceeds potential profit.

Tools: Formal verification, game theory analysis.

Exploit complexity: Very High — requires being the last revealer and having profitable manipulation opportunity.

AI-A score: 1 — Cryptographic protocol + game theory, not source code audit.

C. Cryptographic Vulnerabilities ​

C1 — ECDSA Nonce Reuse (Private Key Recovery) ​

Description: ECDSA signing uses a random nonce k. If the same k is reused to sign two different messages with the same private key, the private key can be algebraically recovered: d = (s1*k - z1) / r. This applies to Bitcoin, Ethereum, and any ECDSA-based system.

Real-world example: Bitcoin: In 2013, Android's SecureRandom bug caused repeated k values. ~55 BTC stolen from Android wallet users. Blockchain.info also had a nonce reuse bug. Sony PS3 (2010) — notoriously used a static k for ECDSA firmware signatures, allowing recovery of the signing key and jailbreaking the console. Ethereum: multiple poorly-implemented off-chain signers reused nonces.

Detection method: Scan blockchain for duplicate r values in ECDSA signatures. For source code, check RNG usage in signing functions. RFC 6979 (deterministic k from HMAC_DRBG) should be used.

Tools: blockchain-ecdsa-nonce-reuse scanners, custom Python/Go scripts. ecdsa-nonce-recovery tools on GitHub.

Exploit complexity: Low — algebraic recovery from two signatures with same r.

AI-A score: 2 — LLMs can flag missing RFC 6979 in ECDSA implementations. But detecting nonce reuse requires analyzing signature values (not source code alone) or flagging non-cryptographic RNG usage.

C2 — Weak Randomness / Predictable Nonces ​

Description: Nonce k generated from a weak entropy source (e.g., rand(), Math.random(), timestamp-based, or low-entropy seed). An attacker who can predict or brute-force k can recover private keys. This is the most common cryptographic failure in blockchain contexts.

Real-world example: Profanity vanity address generator — used 32-bit seeds for Ethereum address generation. ~$160M stolen across multiple addresses in 2022-2023. The Wintermute hack (Sep 2022, $162M) was directly caused by Profanity-generated addresses. Bitcoin brain wallets — users created private keys from low-entropy passphrases, leading to automated theft.

Detection method: Audit RNG source in key generation and signing. Check for non-CSRNG sources (rand(), Math.random(), time(), process_id). Verify seed entropy bounds.

Tools: Manual review of key generation code. Entropy estimation tools. Profanity-specific scanners.

Exploit complexity: Low-Medium — brute-force the seed space, derive private keys, drain.

AI-A score: 3 — LLMs flag non-CSRNG usage in key generation. But quantifying "is this seed space brute-forceable?" requires entropy calculation that LLMs approximate poorly.

C3 — Improper Curve Implementation ​

Description: Custom elliptic curve implementations with subtle mathematical bugs:

  • Not checking that points are on the curve (invalid curve attack — submit point on weak curve, recover key via small-subgroup attack).
  • Twist security: not checking that points are on the curve (not the twist).
  • Missing subgroup check (small subgroup confinement attack).
  • Curve parameters chosen with backdoors.
  • Side-channel leakage (timing, power analysis).

Real-world example: OpenSSL ECDSA nonce bias (CVE-2016-2177) allowed key recovery. Golang's crypto/elliptic P-256 had timing side-channel (CVE-2019-6486). Multiple "custom curve" blockchain projects with unaudited ECC.

Detection method: Verify standard curve is used (secp256k1, P-256, Curve25519). Verify point validation (on-curve check, subgroup check). Verify constant-time operations.

Tools: ECG (Elliptic Curve Graph tool), ECB (Elliptic Curve Browser), SageMath, manual cryptographic audit.

Exploit complexity: Very High — requires elliptic curve cryptanalysis expertise.

AI-A score: 1 — Cryptographic implementation audit requires mathematical verification (point validation, subgroup checks, constant-time analysis) that is far beyond LLM capability.

C4 — ZK Circuit Under-Constraints ​

Description: Zero-knowledge circuits express computation as constraints over finite fields. An under-constrained circuit has missing constraints, allowing a malicious prover to generate valid proofs for invalid statements (e.g., "I have 1 ETH but I'm withdrawing 100 ETH"). This is the most dangerous ZK bug class.

Real-world example: Zcash "Infinite Counterfeit Bug" (2019) — under-constrained Sprout circuit allowed forging proofs to create counterfeit ZEC. Fixed before exploitation. ZKP system bug in privacy-preserving Ethereum mixer led to stolen funds.

Detection method: Formal verification of circuit constraints. Check each output signal has a constraint. Check that all branches execute (no unconstrained selectors). Verify rank-1 constraint system completeness.

Tools: Circom snarkjs for constraint checking, Ecne (automated under-constraint detection), QED, Juvix, Certora for ZK circuits. Manual review with constraint coverage tools.

Exploit complexity: High — requires understanding ZK circuit design and constraint systems.

AI-A score: 1 — ZK circuit constraint systems are mathematical artifacts. LLMs cannot enumerate constraints or reason about constraint completeness from circuit source code.

C5 — ZK Trusted Setup Compromise (Toxic Waste Exposure) ​

Description: Groth16 and some other ZK proving systems require a "trusted setup" ceremony where participants generate parameters. If a participant keeps their "toxic waste" (secret randomness), they can forge proofs indefinitely. The ceremony must have at least one honest participant.

Real-world example: No known exploitation. Zcash held a multi-party ceremony (6 participants originally for Sprout, 200+ for Sapling). Aleo, Aztec, and others had ceremonies. If all participants in a small ceremony colluded, the system would be broken.

Detection method: Verify ceremony transcript. Check number of participants. Verify MPC protocol used for parameter generation. NOT a source code vulnerability — it's a setup process concern.

Tools: Ceremony verification tools, transcript validators.

Exploit complexity: Very High — requires compromising ALL ceremony participants or the ceremony coordinator.

AI-A score: 1 — Trusted setup is a process/protocol concern, not a source code vulnerability.

C6 — MPC/TSS Side-Channel Attacks ​

Description: Multi-Party Computation and Threshold Signature Schemes are vulnerable to side-channel attacks during key generation or signing. Timing, power, EM radiation, or cache-based attacks can leak key shares.

Real-world example: GG18/G G20 TSS protocols had a theoretical key-recovery attack discovered by Dolev et al. (2021) where a malicious participant uses inconsistent R values during signing MPC rounds to recover other parties' shares over multiple signings. Multiple TSS library CVEs.

Detection method: Audit MPC implementation for constant-time operations. Check for known protocol vulnerabilities (GG18, GG20). Verify zero-knowledge proofs within MPC rounds.

Tools: Manual cryptographic audit. Specialized MPC simulators.

Exploit complexity: Very High — cryptographic protocol analysis with real-world attack implementation.

AI-A score: 1 — MPC/TSS protocols are complex multi-round cryptographic protocols. LLMs have no capability here.

C7 — BLS Signature Aggregation Bugs ​

Description: BLS signatures support aggregation (combining multiple signatures into one). Bugs in aggregation:

  • Rogue key attack: When aggregating public keys, an attacker can choose their key as a function of others' keys to cancel them out (e.g., pk_attacker = g^x / pk_honest; aggregated key = g^x). Mitigated by Proof of Possession (PoP) or using multiplicative key aggregation.
  • Signature aggregation without distinct message hashing.

Real-world example: Ethereum 2.0 uses BLS for validator signatures. The spec requires Proof of Possession for validator keys. Early BLS implementations in Cosmos chain had aggregation bugs. BLS is used in Dfinity/ICP, Chia, Filecoin.

Detection method: Verify PoP validation. Check aggregation method (additive = vulnerable without PoP, multiplicative = safe).

Tools: Manual cryptographic review. BLS-specific static analysis.

Exploit complexity: High — subtle cryptographic attack.

AI-A score: 1 — BLS aggregation attacks require cryptographic protocol-level reasoning.

C8 — VRF Manipulation ​

Description: Verifiable Random Function produces a random output and a proof that the output is correct. Bugs:

  • The VRF proof verification accepts invalid proofs.
  • The VRF seed is predictable.
  • The VRF output can be biased if the prover can choose inputs after seeing partial output.
  • The VRF implementation uses a weak curve.

Real-world example: Chainlink VRF v1 had concerns about the on-chain verification cost; v2 improved this. No major VRF exploitation known, but VRF is used for NFT mints, DAO elections, and lottery contracts where manipulation would be profitable.

Detection method: Verify VRF proof verification uses standard library (Chainlink, libsecp256k1). Check that VRF seed includes all necessary entropy sources. Verify curve and hashing primitives.

Tools: Manual cryptographic audit. Verify against Chainlink VRF implementation.

Exploit complexity: High — requires finding flaw in VRF proof verification.

AI-A score: 1 — Cryptographic verification logic, requires mathematical reasoning.

C9 — Merkle Tree Second Preimage Attacks ​

Description: Merkle tree leaves are concatenated and hashed. If leaf length is not explicitly distinguished, hash(A || B) where A and B are leaves collides with hash(X) where X = A || B is a single leaf at a higher level. Mitigated by using different prefixes for leaf vs. internal nodes or fixed-size leaves.

Real-world example: Bitcoin's original merkle tree implementation (pre-BIP) was theoretically vulnerable to second preimage attacks for SPV proofs. Most modern implementations (OpenZeppelin's MerkleProof) use double-hashing or domain separation.

Detection method: Check if leaf hashing uses different encoding than internal node hashing. Check for domain separator bytes.

Tools: Slither (custom detector for merkle proof verification), manual review.

Exploit complexity: Medium — requires crafting a colliding merkle proof.

AI-A score: 3 — LLMs understand the leaf-vs-internal-node distinction and can check for domain separators. But the collision construction requires more than just code review.

C10 — Commitment Scheme Breakage ​

Description: Commit-reveal schemes depend on the binding and hiding properties of the commitment. If the commitment can be broken:

  • Hash commitment with low-entropy nonce (brute-forceable).
  • Homomorphic commitment where nonce algebra allows manipulation.
  • Commitment with truncated hash allowing collision.

Real-world example: Multiple on-chain rock-paper-scissors and commit-reveal auction games were exploited because commitments were keccak256(value) without a nonce, allowing precomputation of all possible hashes.

Detection method: Check commitment construction. Verify nonce inclusion, entropy bounds, and hash collision resistance.

Tools: Manual review primarily. Echidna property fuzzing.

Exploit complexity: Low-Medium — depends on entropy and construction.

AI-A score: 3 — LLMs can check for nonce presence and nonce entropy in commitment schemes. But full cryptanalysis of commitment binding is harder.

D. Node Implementation Vulnerabilities ​

D1 — RPC/JSON-RPC Authentication Bypass ​

Description: Blockchain nodes expose JSON-RPC endpoints. If exposed to the internet without authentication, attackers can:

  • eth_sendTransaction to drain the node's accounts.
  • personal_unlockAccount to unlock wallets.
  • admin_* and debug_* APIs for full node control.
  • miner_setEtherbase to redirect mining rewards.

Real-world example: Hundreds of thousands of Ethereum nodes have exposed RPC on port 8545 at various times. In 2018, a group scanned for exposed RPC and stole from nodes with unlocked accounts. In 2022, researchers found 3,000+ Ethereum nodes with exposed RPC. BNB Chain nodes similarly exposed on port 8575.

Detection method: Check if --rpcaddr is 0.0.0.0 and no authentication is configured. Check firewall rules. Scan for open 8545/8546/8575/30303 ports.

Tools: Shodan, Masscan, Nmap, custom RPC scanners. eth-cli tools.

Exploit complexity: Very Low — scan, connect, drain.

AI-A score: 4 — LLMs can check RPC bind address and auth config in node config files. But this is more of an infrastructure configuration issue than source code vulnerability.

D2 — P2P Message Parsing Bugs ​

Description: Blockchain nodes parse complex P2P messages (blocks, transactions, consensus messages). Bugs in parsers can lead to:

  • Buffer overflow/underflow in message deserialization.
  • Integer overflow in message length fields.
  • Format string vulnerabilities in log messages containing P2P data.
  • Deserialization of untrusted data leading to RCE.

Real-world example: Bitcoin CVE-2018-17145 (inventory message OOM — a crafted INV message caused excessive memory allocation, crashing the node). Ethereum — py-evm had deserialization bugs. Solana — multiple crashes from malformed transactions.

Detection method: Fuzz P2P message handlers. Check for unsafe deserialization. Look for memory-unsafe operations in C/C++/Rust unsafe blocks.

Tools: AFL++, libFuzzer, cargo-fuzz (Rust), go-fuzz (Go). AddressSanitizer, MemorySanitizer.

Exploit complexity: High — requires crafting malformed P2P messages that trigger memory corruption.

AI-A score: 2 — LLMs can flag obvious unsafe patterns (unchecked length, raw pointer arithmetic) but finding exploitable memory corruption requires fuzzing and exploit development. LLMs supplement but don't replace fuzzing.

D3 — Denial of Service via Gossip/Mempool ​

Description: Attackers flood the gossip network or mempool with:

  • Invalid transactions that are expensive to validate.
  • Transactions that fill mempools, evicting legitimate transactions.
  • Block proposals that are computationally expensive to verify.
  • Peer connection floods exhausting connection slots.

Real-world example: Ethereum September 2022 — a block with extremely expensive state access pattern caused validators to miss attestations. Solana (multiple occasions) — transaction floods caused network halts (Sep 2021 17-hour outage, Apr 2022 7-hour outage). Bitcoin — mempool flooding as a fee-market attack.

Detection method: Check transaction validation costs. Check rate limiting on peer connections. Verify CPU-bound validation is bounded.

Tools: Load testing, simulation frameworks, chaos engineering.

Exploit complexity: Low-Medium — just flood with crafted transactions.

AI-A score: 1 — DoS resilience requires performance testing and system-level analysis, not source code audit.

D4 — State Sync / Snapshot Import Bugs ​

Description: Nodes can sync from a trusted state snapshot to avoid full sync. Malicious snapshots can corrupt state, cause panics, or inject invalid state that the node then attests to.

Real-world example: Ethereum state sync via snap sync is trust-minimized (snapshots are verified against the header chain). But custom snapshot formats from third parties introduce risk. Some Cosmos SDK chains had snapshot import crashes from malformed state data.

Detection method: Check snapshot integrity verification (merkle proofs, state root validation). Check deserialization of snapshot data.

Tools: Fuzzing snapshot import, integrity verification audit.

Exploit complexity: Medium — distribute a malicious snapshot.

AI-A score: 2 — LLMs can verify integrity checks but cannot fuzz the snapshot parser.

D5 — Configuration Exposure ​

Description: Node configuration exposes debug APIs, admin interfaces, or unprotected management endpoints.

Real-world example: Geth's --http.api debug,admin,personal if bound to 0.0.0.0 gives full control. BNB Chain nodes with --http.api eth,net,web3,personal,debug exposed. Many validator nodes expose Prometheus/Grafana metrics endpoints without auth.

Detection method: Check config files for exposed API modules. Check for debug/admin API binding on public interfaces.

Tools: Configuration scanners, Shodan, Nmap.

Exploit complexity: Very Low — scan and connect.

AI-A score: 3 — LLMs can check config files for dangerous API exposure flags. But node config is often environment-specific and not in source code.

D6 — Chain Reorganization Exploitation ​

Description: Bugs in chain reorganization handling can cause double-spends, incorrect balance tracking, or node crashes. Deep reorgs (reorganizing many blocks) exercise edge cases in reorg logic.

Real-world example: Ethereum 2022 — a 7-block reorg caused issues for some clients. Bitcoin 2013 — a >24-block reorg due to a BerkeleyDB bug (0.7 to 0.8 upgrade) caused a chain split.

Detection method: Test reorg handling with simulation frameworks. Check transaction index rebuild logic. Verify UTXO set / state trie updates during reorg.

Tools: Client test suites, simulation frameworks, chaos testing.

Exploit complexity: High — requires causing a deep reorg, which requires hashpower or consensus bug.

AI-A score: 1 — Reorg handling is complex state-machine logic tested via simulation, not amenable to LLM audit.

D7 — Database/Storage Corruption ​

Description: Bugs in the node's database layer (LevelDB, RocksDB, MDBX) can corrupt chain state, cause panics, or lead to incorrect state reads. Corrupted state can cause the node to build on invalid blocks.

Real-world example: Ethereum Geth had LevelDB corruption issues during shutdown, causing database inconsistency. Erigon (Ethereum client) has had MDBX corruption bugs. Bitcoin Core LevelDB corruption issues.

Detection method: Check database write atomicity. Check error handling on DB reads/writes. Verify crash consistency.

Tools: Database integrity checkers, fsync/flush correctness analysis.

Exploit complexity: High — requires corrupting the database file.

AI-A score: 1 — Database engine bugs require storage-layer testing and are not amenable to static analysis.

E. Wallet & User-Facing Vulnerabilities ​

E1 — Blind Signing / Transaction Simulation Spoofing ​

Description: Users sign transactions/Hashes without understanding what they authorize. Wallet simulation (e.g., "this transaction will transfer 1 ETH to X") can be spoofed. The simulation may use different state than what executes on-chain (state drift, frontrunning). Or the dApp deliberately shows misleading simulation data.

Real-world example: Widespread phishing campaigns target wallet users with "approve all" signatures. In 2024, an attacker deployed a fake Uniswap frontend where the simulation showed a swap but the actual transaction was an approve(all) to the attacker.

Detection method: Not a code vulnerability. Check wallet simulation implementation. Verify simulation state matches execution state.

Tools: Wallet Guard, Pocket Universe, Fire, Blocksec Phalcon.

Exploit complexity: Low — social engineering, not technical exploitation.

AI-A score: 1 — Social engineering and frontend manipulation, not source code audit.

E2 — Address Poisoning / Scam Token Attacks ​

Description: Attacker sends a small amount of token or ETH from an address that matches the first/last N characters of a victim's frequent counterparty. Or creates a scam token with the same name/symbol as a legitimate one. The victim copies the wrong address from their transaction history.

Real-world example: Widespread on Ethereum, BSC, Tron. Attackers use profanity2 or custom vanity address generators to create addresses matching 4-6 characters of victims' counterparties. MetaMask added address poisoning detection. $100M+ collectively lost to this across all chains.

Detection method: Not a contract vulnerability. Wallet-level detection: flag addresses with matching prefixes/suffixes.

Tools: Wallet Guard, Web3 Antivirus, MetaMask built-in detection.

Exploit complexity: Very Low — just send dust transactions and wait.

AI-A score: 1 — Address-level attack detectable by pattern matching on blockchain data, not by source code audit. AI agents can build scanners for this though.

E3 — Clipboard Hijacking ​

Description: Malware on the victim's machine monitors clipboard for crypto addresses and replaces them with attacker-controlled addresses. When the victim pastes, they paste the attacker's address.

Real-world example: Multiple malware families (CryptoShuffler, Evrial, ComboJack) specifically target crypto addresses in clipboard. Individual losses range from $1K to $100K+. In 2022-2023, clipboard hijackers were the most common crypto-stealing malware.

Detection method: Not a blockchain vulnerability — it's endpoint malware. Detection via EDR, anti-malware.

Tools: Endpoint security tools, clipboard monitoring.

Exploit complexity: Very Low (for the attacker who wrote the malware), N/A for blockchain auditors.

AI-A score: 1 — Endpoint malware, not source code audit.

E4 — Wallet/Extension Extraction Vulnerabilities ​

Description: Vulnerabilities in browser extension wallets (MetaMask, Phantom, Rabby) or mobile wallets that allow extraction of private keys, seed phrases, or signing keys via:

  • XSS in the wallet's popup/settings page.
  • Malicious browser extension with excessive permissions.
  • Mobile wallet local storage not encrypted.
  • Insecure IPC between wallet extension and dApp.

Real-world example: MetaMask: multiple security vulnerabilities fixed (CVE-2020-11882 — address bar spoofing, 2023 — phishing via extension messaging). Phantom wallet had a recovery phrase exposure bug via the extension's developer console.

Detection method: Audit extension manifest permissions. Check message passing security. Check storage encryption. Check CSP headers in wallet HTML.

Tools: Browser extension security scanners, manual extension audit.

Exploit complexity: Low-Medium (depends on specific vulnerability). XSS in extension = Low.

AI-A score: 2 — LLMs can audit extension manifest, CSP, and basic permission hygiene. But browser extension security is nuanced and LLMs miss platform-specific attack vectors.

E5 — Hardware Wallet Side Channel ​

Description: Hardware wallets (Ledger, Trezor, GridPlus) are vulnerable to physical side-channel attacks:

  • Power analysis during PIN entry or signing.
  • EM emanation analysis.
  • Glitching (voltage/clock fault injection).
  • Cold-boot attacks on RAM.
  • Supply chain attacks (tampered device).

Real-world example: Ledger: "Ledger Donjon" researchers demonstrated multiple attacks on their own devices (fixed in firmware). Trezor: Kraken Security Labs demonstrated a voltage glitching attack extracting the seed (Trezor One, requires physical access, fixed). Ledger supply chain attack (Dec 2023) — attacker compromised Ledger's Connect Kit NPM package, injecting drainer code (not a physical attack, but supply chain).

Detection method: Hardware security evaluation lab tests. Firmware audit. Supply chain verification.

Tools: Oscilloscopes, ChipWhisperer, glitching rigs. Hardware security lab equipment.

Exploit complexity: High (physical access needed) to Very High (side-channel, lab equipment). Low for supply chain.

AI-A score: 1 — Hardware attacks require physical lab equipment and electrical engineering expertise.

E6 — Seed Phrase / BIP39 Issues ​

Description: BIP39 seed phrases, implementation, and handling vulnerabilities:

  • Non-standard wordlists (reducing entropy).
  • Weak entropy sources for seed generation.
  • Seed phrase stored insecurely (plaintext on device, cloud backup without encryption).
  • Poor PBKDF2/SHA-512 derivation implementation.
  • Using BIP39 passphrase incorrectly (thinks passphrase is the seed).

Real-world example: The Profanity vanity address generator (used 32-bit seeds, ~$160M stolen). Multiple mobile wallets found storing seed phrases in plaintext in app data or logs. A wallet app in 2022 used Math.random() for seed generation (predictable, could be brute-forced).

Detection method: Audit seed generation for CSRNG usage. Check BIP39 wordlist is standard (2048 words). Verify PBKDF2 parameters (2048 iterations minimum). Check how seed is stored.

Tools: Manual wallet audit. Entropy estimation tools.

Exploit complexity: Low-Medium — depends on the entropy/derivation flaw.

AI-A score: 2 — LLMs can check for standard BIP39 wordlists and CSRNG. But entropy estimation and side-channel storage analysis require runtime and platform context.

E7 — WalletConnect / dApp Bridge Attacks ​

Description: WalletConnect v1/v2 protocol attacks:

  • Session hijacking via exposed WalletConnect URI.
  • Malicious dApp impersonating legitimate dApp in WalletConnect session.
  • Man-in-the-middle on WalletConnect relay/bridge.
  • WalletConnect v2 relay can censor or delay messages.
  • QR code phishing — fake WalletConnect QR codes.

Real-world example: WalletConnect v1 bridge was centralized (bridge.walletconnect.org), creating censorship risk. WalletConnect v2 moved to a decentralized relay network. Multiple phishing cases where attackers sent fake WalletConnect links.

Detection method: Check WalletConnect protocol implementation. Verify relay security model. Check session management.

Tools: WalletConnect protocol security audit. Penetration testing of relay infrastructure.

Exploit complexity: Medium — requires understanding WalletConnect protocol.

AI-A score: 2 — LLMs can audit WalletConnect SDK integration for basic issues (session validation, URI exposure). Protocol-level attacks require network-level testing.

F. DeFi Economic Vulnerabilities ​

F1 — Impermanent Loss Manipulation ​

Description: Impermanent loss (IL) is the difference between holding assets vs. providing liquidity to an AMM. While IL itself is a known risk, attackers can induce IL on LP providers by manipulating the pool price, causing LPs to exit at a loss, and extracting the difference as profit.

Real-world example: Not a single headline exploit (IL is "by design"), but attackers who manipulate thin-liquidity pools cause LPs to suffer severe IL. This is heavily intertwined with oracle manipulation attacks.

Detection method: Analyze AMM pool depth. Check if LP exit can be forced. Verify protocol doesn't expose LPs to single-block massive slippage.

Tools: Economic simulation, pool depth analysis, Gauntlet/Chaos Labs risk parameters.

Exploit complexity: Medium — manipulate pool, LPs exit at loss.

AI-A score: 1 — Economic simulation required, not source code audit.

F2 — TWAP Manipulation ​

Description: TWAP (Time-Weighted Average Price) oracles are meant to resist manipulation by averaging over time. However, if the TWAP window is short (e.g., 5 minutes) and the attacker can sustain manipulation for that window (using flash-loaned capital), the TWAP can still be manipulated.

Real-world example: Inverse Finance (Jun 2022, $1.2M, INV token TWAP manipulated). Deus Finance (Mar 2022, $3M, DEI stablecoin TWAP). Rikkei Finance (Apr 2022). These all used Uniswap V2-style TWAP with insufficient window or low-liquidity pools.

Detection method: Check TWAP window length. Check pool liquidity depth. Simulate flash-loan manipulation attack. Compare required capital to manipulate vs. pool TVL.

Tools: Echidna, Foundry invariant tests, economic simulation. Chaos Labs / Gauntlet parameter recommendations.

Exploit complexity: High (requires sustained manipulation across multiple blocks).

AI-A score: 1 — Requires liquidity data, economic simulation, and capital cost analysis. Not a source code pattern.

F3 — Price Feed Staleness ​

Description: Oracle provides price data, but the price has not been updated recently. The protocol uses stale data for liquidations, borrowing limits, or collateral valuation.

Real-world example: Venus Protocol (May 2021, $200M+) — LUNA and XVS price feeds were stale, allowing borrowing against overvalued collateral. Chainlink feeds have a heartbeat (typically 1-24 hours) and a deviation threshold; if both are missed, the price is stale.

Detection method: Check for latestAnswer() or latestRoundData() without updatedAt timestamp check. Check for stale price thresholds.

Tools: Slither (Chainlink-specific detectors exist), manual review, Tenderly simulation.

Exploit complexity: Medium — wait for stale price, borrow against inflated collateral.

AI-A score: 4 — Very concrete pattern: check latestRoundData() call and verify updatedAt is checked against a staleness threshold. LLMs catch this reliably.

F4 — Fee Miscalculation ​

Description: Bugs in fee calculation logic leading to incorrect fee application:

  • fee = amount * feePercent / DENOMINATOR but feePercent can be set to > DENOMINATOR.
  • Rounding direction favors attacker (protocol rounds down fee, rounds up refund).
  • Fee rate can be changed without timelock.
  • Fee-on-transfer interactions double-count fees.

Real-world example: Multiple DeFi forks where the fee denominator (FEE_DENOMINATOR) was incorrectly set or fee rate was unbounded. An attacker who could set feePercent = 10000 on a 10000-denominator would charge 100% fees, stealing all user funds in fee extraction.

Detection method: Check fee calculation for rounding direction. Check if fee parameters are bounded. Check for fee rate timelock.

Tools: Echidna, Foundry fuzz/unit tests, Slither (bound checks).

Exploit complexity: Low — if fee is unbounded, set to max.

AI-A score: 3 — LLMs trace fee calculation arithmetic and check bounds. But understanding whether rounding accumulates exploitably requires simulation.

F5 — LP Token Inflation Attack ​

Description: First liquidity provider to a Uniswap V2-style pool can mint LP tokens and then manipulate the pool to inflate the LP token price, making subsequent depositors receive fewer LP tokens than expected. The attacker then exits with more than they deposited.

Real-world example: Not a single exploit — this is inherent to Uniswap V2 AMM design. The standard mitigation is to burn the first 1000 wei of LP tokens to a dead address. Some protocols forgot this.

Detection method: Check if minimum liquidity is minted/burned on first deposit. Check if MINIMUM_LIQUIDITY is sent to address(0) or address(0xdead).

Tools: Manual review, Slither (custom detectors).

Exploit complexity: Low — just be the first depositor.

AI-A score: 3 — LLMs check for MINIMUM_LIQUIDITY and dead-address burn. Standard pattern is well-known.

F6 — Vault Share Inflation (First Depositor Attack / ERC-4626) ​

Description: In ERC-4626 vaults, shares = assets * totalSupply / totalAssets. If totalSupply and totalAssets are near zero (first deposit), a small donation to the vault inflates totalAssets. The first depositor gets 1 wei of shares while the vault holds much more, letting them redeem at a profit. Or conversely, the first depositor can manipulate the share price so subsequent depositors get 0 shares.

Real-world example: The ERC-4626 "first depositor inflation attack" is a well-documented design concern. Yearn and other vault protocols implemented mitigations (initial deposit minimum, dead shares). Multiple ERC-4626 implementations without mitigation were flagged in audits.

Detection method: Check if the vault has an initial deposit minimum. Check if "dead shares" are minted to prevent zero-totalSupply manipulation. Check if previewDeposit/previewMint return 0 for small amounts.

Tools: Slither (ERC-4626 specific), manual review, foundry tests.

Exploit complexity: Low — front-run as first depositor.

AI-A score: 4 — LLMs recognize ERC-4626 share calculation and check for standard mitigations (dead shares, minimum deposit). Well-documented pattern.

F7 — Donation Attack (Balancer / Aura Style) ​

Description: In protocols where rewards/staking is proportional to a user's share of the pool, an attacker can donate assets to the pool, inflating totalAssets without minting new shares. This dilutes all existing stakers since their share represents a smaller fraction of the total pool. The attacker then claims a disproportionate amount of rewards.

Real-world example: Euler Finance exploit (Mar 2023, $197M) involved a donation attack to manipulate the totalSupply/totalAssets ratio of eTokens, allowing the attacker to borrow more than their collateral. The Aura Finance exploit (Aug 2023) used a similar donation-to-inflate mechanism.

Detection method: Check if totalAssets can be manipulated by direct transfers without share minting. Verify that reward/share accounting uses a snapshot or checkpointed timestamp.

Tools: Echidna, Foundry invariant tests ("shares * totalAssets / totalSupply should not decrease after donation").

Exploit complexity: Medium-High.

AI-A score: 2 — LLMs understand the donation-to-dilute concept but tracking cross-contract asset flows that cause dilution requires complex data-flow analysis.

F8 — Rebasing Token Attacks ​

Description: Rebasing tokens (stETH, aTokens, sDAI) automatically adjust balances to reflect accrued yield. Protocols that don't account for rebasing can have:

  • Internal balance tracking diverges from actual balance.
  • Rewards double-counted.
  • Withdrawals reverting because internal accounting shows more than actual balance.
  • Shares/rate manipulation via rebase.

Real-world example: Multiple DeFi protocols had bugs with stETH integration. Aave integration with stETH required careful handling of rebasing. Several forks of yield aggregators broke on rebasing tokens because they assumed static balances.

Detection method: Check if protocol uses balanceOf() before and after operations or relies on cached balances. Check for _beforeTokenTransfer hooks that assume static balances.

Tools: Manual review, fork testing with rebasing token mocks.

Exploit complexity: Medium — requires deploying a rebasing token and finding the accounting mismatch.

AI-A score: 2 — LLMs can identify that a protocol assumes static balances. But verifying all accounting paths are rebase-safe requires multi-path simulation.

Summary: AI-Auditability Rankings ​

Tier 1: LLM Finds Reliably (Score 4-5) — Build Methodology Guides First ​

These have clear syntactic patterns or simple semantic checks. The AI agent can detect them from source code alone with high confidence.

RankVulnerability ClassScoreKey Pattern
1Floating Pragma (SWC-103)5pragma solidity ^
2Outdated Compiler (SWC-102)5Version < latest stable
3Integer Overflow (SWC-101)5unchecked + arithmetic
4Deprecated Functions (SWC-111)5sha3(), throw, suicide()
5tx.origin Auth (SWC-115)5tx.origin in require/if
6Unprotected SELFDESTRUCT (SWC-106)5selfdestruct w/o auth
7Incorrect Constructor (SWC-118)5Old-style constructor mismatch
8Hardcoded Gas (SWC-134)5.transfer(), .call{gas: X}()
9Unused Variables (SWC-131)5Unused state/local variables
10Unprotected Ether Withdrawal (SWC-105)4transfer/send w/o auth
11Unchecked Call Return (SWC-104)4.call() w/o require check
12Uninitialized State (SWC-108)4Uninitialized address vars
13Uninitialized Storage Ptr (SWC-109)4Uninitialized struct in storage
14Delegatecall to Untrusted (SWC-112)4delegatecall user-controlled addr
15DoS Block Gas Limit (SWC-128)4Unbounded loops over arrays
16ABI EncodePacked Collision (SWC-133)4keccak256(abi.encodePacked(...))
17Access Control (SWC-105+)4Missing onlyOwner/onlyRole
18Infinite Mint (custom)4Auth on mint functions
19Stale Price Feed (DeFi)4Missing updatedAt check
20ERC-4626 Vault Share Inflation (DeFi)4Missing dead shares
21Dead Code (SWC-135)4x == y; standalone

Tier 2: LLM Needs Tool Assistance (Score 3) — Build After Tier 1 ​

These require moderate contextual reasoning. LLM can flag the suspicious pattern but needs simulation/invariant testing to confirm exploitability.

RankVulnerability ClassScoreWhy Not Higher
22Reentrancy (SWC-107)3Cross-function/cross-contract complexity
23DoS with Failed Call (SWC-113)3Business context needed
24Timestamp Dependence (SWC-116)3Need to assess margin of manipulation
25Signature Malleability (SWC-117)3Crypto implementation detail
26State Shadowing (SWC-119)3Cross-file inheritance
27Weak Randomness (SWC-120)3Context: how critical is randomness?
28Lack of Sig Verification (SWC-122)3Multi-function flow
29Unexpected Ether Balance (SWC-132)3Accounting impact analysis
30Unencrypted On-Chain Data (SWC-136)3PII vs. non-sensitive distinction
31Upgrade Proxy Bugs3Storage layout version comparison
32Signature Replay (SWC-121)3Cross-chain + meta-tx context
33Weak Randomness (Crypto C2)3Entropy estimation
34Merkle Second Preimage (Crypto C9)3Domain separator analysis
35Commitment Breakage (Crypto C10)3Entropy + binding analysis
36Fee Miscalculation (DeFi F4)3Rounding + bound analysis
37LP Token Inflation (DeFi F5)3MINIMUM_LIQUIDITY check
38Config Exposure (Node D5)3Config file analysis

Tier 3: Beyond LLM Source Audit (Score 1-2) — Do Not Prioritize for AI Agent ​

These require economic simulation, cryptographic mathematics, fuzzing, protocol-level game theory, or off-chain context. The AI agent cannot reliably detect these from source code alone.

RankVulnerability ClassScoreWhy Impossible
39Flash Loan Attacks1Multi-protocol economic simulation
40Oracle Manipulation (except stale check)2Need liquidity data + economic model
41Governance Attacks1Off-chain voting dynamics
42MEV Exploits1Mempool + relay infrastructure
43Cross-Chain Bridge Attacks1Multi-chain validator set analysis
44Read-Only Reentrancy1Multi-contract data flow subtlety
45RTLO Control Character (SWC-130)1Byte-level encoding invisible to LLM
46Insufficient Gas Griefing (SWC-126)1Opcode-level gas accounting
47Arbitrary Jump (SWC-127)1Bytecode-level analysis
48Typographical Errors (SWC-129)2LLM "reads through" typos
49Fee-on-Transfer Tokens2Need token contract cross-analysis
50ERC-777 Reentrancy2Cross-contract token behavior
51Permit Signature Phishing1Social engineering, not code
52Precision Loss / Rounding2Needs simulation to confirm exploitability
53All Protocol/Consensus Layer (B1-B11)1Consensus protocols, game theory
54ZK Circuit Under-Constraints (C4)1Constraint system mathematics
55Trusted Setup Compromise (C5)1Process, not code
56MPC/TSS Side Channel (C6)1Cryptographic protocol math
57BLS Aggregation Bugs (C7)1Cryptographic protocol math
58VRF Manipulation (C8)1Cryptographic verification logic
59Improper Curve Implementation (C3)1Elliptic curve mathematics
60ECDSA Nonce Reuse (C1)2Need signature data, not just source
61Node P2P Parsing Bugs (D2)2Requires fuzzing
62Node DoS/Gossip (D3)1Requires load testing
63Node State Sync Bugs (D4)2Requires fuzz/simulation
64Node Chain Reorg Bugs (D6)1Requires simulation
65Node DB Corruption (D7)1Requires storage-layer testing
66Wallet Blind Signing (E1)1Social engineering
67Address Poisoning (E2)1Blockchain data scanning (not source)
68Clipboard Hijacking (E3)1Endpoint malware
69Hardware Wallet Side Channel (E5)1Physical lab equipment
70WalletConnect Bridge Attacks (E7)2Network protocol testing
71Impermanent Loss (F1)1Economic simulation
72TWAP Manipulation (F2)1Requires liquidity data
73Donation Attack (F7)2Cross-contract flow simulation
74Rebasing Token Attacks (F8)2Cross-contract + simulation

Methodology Guide Build Priority ​

Based on the analysis above, the AI agent's attack methodology guides should be built in this order:

Wave 1: Solidity Static Analysis (Tier 1, Score 4-5) ​

Build comprehensive detection modules for all 21 vulnerability classes in Tier 1. These can be implemented as:

  • Slither custom detectors
  • Solhint rules
  • Foundry test generators (auto-generate property tests for detected patterns)
  • LLM prompt templates with clear detection heuristics

Wave 2: Assisted Analysis (Tier 2, Score 3) ​

Build modules that flag suspicious patterns and guide the human auditor:

  • Reentrancy detection with cross-contract call graph visualization
  • Signature vulnerability detection with EIP-712 compliance checking
  • Oracle staleness verification with Chainlink heartbeat integration
  • Upgrade proxy storage layout diff tools

Wave 3: Fuzzing & Simulation Integration (Tier 1-2, supplemental) ​

  • Auto-generate Echidna/Foundry invariant tests from detected vulnerability patterns
  • Integrate with Tenderly/Anvil fork simulation for economic exploits
  • Build cross-contract analysis pipeline for ERC-777 and fee-on-transfer interactions

Wave 4: Protocol & Cryptographic (Tier 3, Score 1-2) ​

These require specialized tools beyond LLM source audit. Build orchestrators that dispatch to:

  • ZK circuit verifiers (Ecne, snarkjs constraint checkers)
  • Fuzzing harnesses (AFL++, go-fuzz, cargo-fuzz) for P2P parsers
  • Economic simulation frameworks for DeFi exploits
  • Cryptographic audit tools for curve/implementation verification

Document version 1.0. Generated 2026-06-05 for AllySec Agent methodology development.

Released under the MIT License.

Copyright 2026 AllySecLabs — The Allied Security Research Guild