smart-contract-vulnerabilities

SKILL: Smart Contract Vulnerabilities — Expert Attack Playbook

AI LOAD INSTRUCTION: Expert smart contract audit techniques. Covers reentrancy (single, cross-function, cross-contract, read-only), integer overflow, access control, delegatecall, randomness manipulation, flash loans, signature replay, front-running/MEV, and CREATE2 exploitation. Base models miss subtle cross-contract reentrancy and storage layout collisions in proxy patterns.

0. RELATED ROUTING

• defi-attack-patterns when the vulnerability is part of a DeFi protocol exploit (flash loans, oracle manipulation, governance attacks)
• deserialization-insecure when the target is off-chain infrastructure deserializing blockchain data

Advanced Reference

Also load SOLIDITY_VULN_PATTERNS.md when you need:

• Side-by-side vulnerable vs fixed code patterns for each vulnerability class
• Gas optimization traps that introduce vulnerabilities
• Proxy pattern storage collision examples with slot calculations

1. REENTRANCY

The most iconic smart contract vulnerability. External calls transfer execution control; if state is not updated before the call, the callee can re-enter.

1.1 Classic Reentrancy (Single-Function)

Victim.withdraw()
  ├── checks balance[msg.sender] > 0          ✓
  ├── msg.sender.call{value: balance}("")     ← external call
  │   └── Attacker.receive()
  │       └── Victim.withdraw()               ← re-enters before state update
  │           ├── checks balance[msg.sender]   ← still > 0!
  │           └── sends ETH again
  └── balance[msg.sender] = 0                 ← too late

1.2 Cross-Function Reentrancy

Two functions share state; attacker re-enters a different function during callback:

1.3 Cross-Contract Reentrancy

Contract A calls Contract B, which calls back into Contract A (or Contract C that reads A's stale state). Especially dangerous in DeFi protocols where multiple contracts share state.

1.4 Read-Only Reentrancy

The re-entered function is a view function used by a third-party contract for price calculation. No state modification in the victim, but the stale intermediate state misleads the reader.

Real-world: Curve pool get_virtual_price() read during remove_liquidity() callback → inflated price → profit on dependent lending protocol.

Mitigations

2. INTEGER OVERFLOW / UNDERFLOW

Pre-Solidity 0.8

Arithmetic silently wraps: uint8(255) + 1 == 0, uint8(0) - 1 == 255.

Post-Solidity 0.8

Default checked arithmetic reverts on overflow. But unchecked{} blocks reintroduce risk:

unchecked {
    // "gas optimization" — but if i can be influenced by user input, overflow returns

SafeMath Bypass Scenarios

• Casting: uint256 → uint128 truncation before SafeMath check
• Assembly blocks: mstore / add bypass Solidity-level checks
• Intermediate multiplication overflow before division: (a * b) / c where a * b overflows

3. ACCESS CONTROL

tx.origin vs msg.sender

Attack: trick owner into calling attacker contract → attacker contract calls victim with owner's tx.origin.

Common Patterns

4. RANDOMNESS MANIPULATION

On-chain randomness sources are predictable to miners/validators:

Commit-reveal bypass: If reveal phase doesn't enforce timeout or bond, attacker can choose not to reveal unfavorable outcomes (selective abort attack).

5. DELEGATECALL VULNERABILITIES

delegatecall executes callee's code in caller's storage context. Storage slot layout must match exactly.

Storage Layout Collision

Implementation writes to someVariable (slot 0) → overwrites proxy's owner. Attacker calls implementation function that writes slot 0 → becomes proxy owner.

Function Selector Collision

4-byte function selectors can collide. If proxy's admin() selector collides with implementation's transfer(), calling admin() on the proxy executes transfer() logic.

Tool: cast selectors <bytecode> (Foundry) to enumerate selectors.

6. FRONT-RUNNING / MEV

Transaction Ordering Manipulation

Protection Patterns

7. SIGNATURE REPLAY

Missing Nonce

Reuse a valid signature to repeat the action (e.g., transfer) multiple times.

Cross-Chain Replay

Same contract deployed on multiple chains with same address → signature valid on all chains. Must include block.chainid in signed message.

EIP-712 Implementation Errors

8. SELF-DESTRUCT & FORCE-SEND ETH

selfdestruct(recipient) force-sends all contract ETH to recipient — bypasses receive() and fallback(), cannot be rejected.

Breaks contracts that rely on address(this).balance for logic (e.g., require(balance == expected)).

Post-EIP-6780 (Dencun): selfdestruct only sends ETH; code/storage deletion only if called in same tx as creation.

9. CREATE2 & DETERMINISTIC ADDRESS EXPLOITATION

CREATE2 address = keccak256(0xff ++ deployer ++ salt ++ keccak256(initCode)).

10. FLASH LOAN ATTACK PATTERNS

Key: entire sequence must succeed atomically or the whole tx reverts.

11. SHORT ADDRESS ATTACK

EVM pads missing bytes in ABI-encoded calldata with zeros. If transfer(address, uint256) is called with a 19-byte address, the uint256 amount shifts left by 8 bits → multiplied by 256.

Mitigation: validate calldata length; modern Solidity compilers add checks.

12. TOOLS

13. DECISION TREE