Immunefi Vulnerability Patterns

Immunefi Vulnerability Patterns & Post-Mortem Audit Playbook

Overview

This skill synthesizes core vulnerability classes, recurring architectural pitfalls, and remediation strategies from the highest-impact vulnerability reports published on Immunefi (reports.immunefi.com). It targets critical flaw categories across decentralized finance (DeFi), bridge protocols, automated market makers (AMMs), and governance layers.

1. Core Threat Categories (Immunefi Taxonomy)

A. Liquidity & Vault Drains

• Empty-Pool Manipulation / Rounding Attacks:
  • Protocols converting assets to shares where low initial liquidity allows integer division truncation to return zero shares or maximize share exchange rates.
  • Invariant: sharePrice must never be manipulable by direct unbacked token transfers (donations).
• First-Deposit Offset & Virtual Shares:
  • Enforce virtual offset (Math.mulDiv with virtual assets + virtual shares) or initial supply burning to mitigate exchange rate skewing.

B. Read-Only Reentrancy Across Cross-Contract Integrations

• Transient State Exposure:
  • Core pools (e.g., Balancer, Curve) execute native asset transfers before internal state updates or while intermediate variables reflect unfinalized pool balances.
  • Third-party lending markets query get_virtual_price() or oracle views during this callback window, pricing collateral at inflated or deflated rates.
• Checklist:
  • Are view/query functions guarded against execution during active pool operations?
  • Does the integrating protocol verify the pool's reentrancy lock before consuming price views?

C. Cross-Chain & Bridge Message Relay Failures

• Unverified Source Address / Bridge Adapters:
  • Message receiving functions (lzReceive, execute, receivePayload) failing to validate that the remote sender contract matches the expected origin address on the source chain.
• Payload Decoding & Type Confusion:
  • Ambiguous abi.decode schemas where variable-length arrays or nested structs lead to parameter injection or payload truncation.
• Gas Limit Exhaustion:
  • Destination chain execution failing silently or leaving assets locked due to insufficient execution gas allocated at source.

D. Flash Loan-Driven Oracle & Reserves Exploitation

• Spot Price Reliance:
  • Using balanceOf(address(this)) or instant AMM reserves (reserve0, reserve1) to compute valuation instead of decentralized, time-weighted or cryptographically verified feeds.
• Chainlink Staleness & L2 Sequencer Downtime:
  • Failure to validate answeredInRound >= roundId, updatedAt != 0, or Sequencer Uptime feeds on Arbitrum, Optimism, and Base.

E. EIP-712 & Permitted Signature Pitfalls

• Domain Separator Invalidation:
  • Omitting block.chainid dynamically, allowing pre-fork signatures to be replayed post-hardfork across competing chains.
• Missing Nonce Invalidation:
  • Allowing multiple executions of meta-transactions or approvals using the same signature.
• High-Order S-Value Malleability:
  • Failing to constrain $s \le \text{secp256k1n}/2$, allowing alternate valid signatures for identical transactions.

2. Comprehensive Security Review Workflow

graph TD
    A[Contract Intake] --> B[Architecture & Asset Flow Map]
    B --> C[Invariant Definition & Invariant Testing]
    C --> D[Oracle & External Integration Audit]
    C --> E[Reentrancy & Execution Ordering Audit]
    C --> F[Token Compatibility & Boundary Checks]
    D --> G[Report Generation & Hardening Verification]
    E --> G
    F --> G

Phase 1: Architecture & Asset Flow Mapping

1. Identify all state-changing entry points that accept external tokens or ETH.
2. Determine trusted vs untrusted actors and privileged administrative roles.
3. Map every external contract interaction, identifying potential hooks (safeTransfer, fallback functions, ERC-777).

Phase 2: Invariant Specification

Every Web3 protocol requires documented invariants prior to audit:

• Solvency Conservation: Vault assets under custody must equal or exceed total depositor claims.
• Monotonicity: Nonces, epoch counts, and reward accrual indices must never decrease.
• Access Boundary: State-modifying admin parameters must strictly obey multi-sig and timelock requirements.

Phase 3: Edge Case & Boundary Verification

• Check zero-amount deposits/withdrawals, maximal uint256 inputs, array lengths, and off-by-one errors in loop terminations.
• Verify safe token handling (SafeERC20) for tokens with non-standard behavior (USDT missing return, fee-on-transfer tokens, rebasing balances).

3. Remediation & Hardening Patterns

Safe Oracle Price Feed Consumption

function getValidatedOraclePrice(
    AggregatorV3Interface priceFeed,
    uint256 maxStalenessPeriod
) internal view returns (uint256) {
    (
        uint80 roundId,
        int256 price,
        ,
        uint256 updatedAt,
        uint80 answeredInRound
    ) = priceFeed.latestRoundData();

    require(price > 0, "Oracle: Negative or zero price");
    require(updatedAt != 0, "Oracle: Incomplete round");
    require(answeredInRound >= roundId, "Oracle: Stale round");
    require(block.timestamp - updatedAt <= maxStalenessPeriod, "Oracle: Price expired");

    return uint256(price);
}

Two-Step Ownership & Role Transfers

Avoid single-step privileged address mutations. Enforce two-step acceptance workflows:

address public pendingAdmin;
address public admin;

event AdminTransferInitiated(address indexed currentAdmin, address indexed pendingAdmin);
event AdminTransferred(address indexed previousAdmin, address indexed newAdmin);

function initiateAdminTransfer(address _newAdmin) external {
    require(msg.sender == admin, "Unauthorized");
    require(_newAdmin != address(0), "Zero address");
    pendingAdmin = _newAdmin;
    emit AdminTransferInitiated(admin, _newAdmin);
}

function acceptAdmin() external {
    require(msg.sender == pendingAdmin, "Unauthorized");
    emit AdminTransferred(admin, pendingAdmin);
    admin = pendingAdmin;
    pendingAdmin = address(0);
}