web3-vulnerabilities

name	Web3 Vulnerabilities
description	Blockchain/Web3 security — smart contract bugs, DeFi exploits, bridge vulnerabilities, NFT/Token exploits, reentrancy, MEV/sandwich attacks, flash loan attacks
tags	["web3","blockchain","ethereum","solidity","smart-contracts","defi","bridge","reentrancy","flash-loan","mev","sandwich","nft","erc20","erc721","dao"]
author	Spectra Security Research
version	1

Web3 Vulnerability Analysis

Overview

This skill analyzes blockchain smart contracts, DeFi protocols, NFT collections, bridges, and Web3 applications for vulnerabilities including reentrancy, logic bugs, economic exploits, and access control issues.

---

⚠️ Authorized Use Only

Permitted Contexts:

• Authorized smart contract audits
• CTF blockchain challenges
• Security research on testnets
• Bug bounty programs with explicit scope

Prohibited:

• Mainnet exploitation without authorization
• Targeting production DeFi protocols without permission
• Any activity that could affect real funds

---

Analysis Phases

Phase 1: Smart Contract Analysis

1.1 Reentrancy Detection

// Vulnerable pattern (The DAO hack pattern):
function withdraw(uint256 amount) public {
    require(balances[msg.sender] >= amount);
    
    // State change happens AFTER external call
    // VULNERABLE: Attacker can re-enter before balance updated
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success, "Transfer failed");
    
    balances[msg.sender] -= amount;
}

// Detection:
// - External call (call, delegatecall, send) before state update
// - State change (balance -= amount) AFTER external call

// Attack:
// Attacker contract calls withdraw()
// In fallback function, calls withdraw() again
// First call hasn't updated balance yet
// Attacker drains contract

Novelty Indicators:

• Cross-contract reentrancy (not just single contract)
• Reentrancy across multiple functions
• Read-only reentrancy (view functions with side effects)
• Flash loan reentrancy (complex variant)

1.2 Integer Overflow/Underflow

// Solidity 0.8+ has built-in overflow checks
// Pre-0.8 was vulnerable:

// Vulnerable (Solidity < 0.8):
uint8 public balance = 255;
function add(uint8 amount) public {
    balance += amount;  // Wraps to 0 if overflow
}

// Modern detection:
// - Check Solidity version (< 0.8 = potential)
// - Look for unchecked arithmetic operations
// - SafeMath library (pre-0.8 alternative)

// Novelty:
// - Overflow in complex calculations
// - Underflow in decrement operations
// - Type casting bugs (uint256 -> uint8)

---

Phase 2: DeFi Flash Loan Attacks

2.1 Flash Loan Logic Bugs

// Flash loan pattern:
function executeOperation(
    address asset,
    uint256 amount,
    uint256 premium,
    address initiator,
    bytes calldata params
) external returns (bool) {
    // VULNERABLE: No validation of:
    // - Loan usage
    // - Repayment guarantee
    // - Side effects
    
    // Attack scenarios:
    // 1. Borrow huge amount
    // 2. Manipulate price (e.g., in DEX)
    // 3. Profit from manipulation
    // 4. Repay + fee
    // 5. Keep profit
    
    return true;
}

// Detection:
// - Missing access control
// - No slippage protection
// - No oracle verification
// - Reentrancy in callback

Novel Attack Types:

• Oracle manipulation during flash loan
• Cross-protocol arbitrage bugs
• Governance manipulation
• Reward/fee calculation exploits

2.2 Price Oracle Manipulation

// Vulnerable price oracle:
function getPrice(address token) public view returns (uint256) {
    // VULNERABLE: Uses on-chain DEX price
    // Can be manipulated with flash loan
    
    IUniswapV2Pair pair = IUniswapV2Pair(uniswapPair);
    (uint112 reserve0, uint112 reserve1, ) = pair.getReserves();
    return reserve1 * 1e18 / reserve0;  // Simplified
}

// Attack:
// 1. Take flash loan
// 2. Swap on DEX to manipulate price
// 3. Use manipulated price for profit
// 4. Repay loan

// Detection:
// - TWAP with insufficient samples
// - Spot price usage
// - No staleness check
// - No low-liquidity protection

---

Phase 3: Bridge Vulnerabilities

3.1 Bridge Validator Bypass

// Cross-chain bridge pattern:
struct BridgeTransfer {
    address from;
    address to;
    uint256 amount;
    uint256 nonce;
    bytes signature;  // Signed by validators
}

function completeBridgeTransfer(BridgeTransfer calldata transfer) external {
    // VULNERABLE: Insufficient signature validation
    require(verifySignature(transfer.signature, transfer), "Invalid signature");
    
    // Issues:
    // - Signature replay possible
    // - Threshold manipulation
    // - Validator key compromise
    
    balances[transfer.to] += transfer.amount;
}

// Detection:
// - Signature replay protection missing
// - Weak threshold (M of N with low M)
// - No nonce uniqueness check
// - Old signature acceptance

3.2 Bridge Liquidity Exploits

// Bridge mint/burn imbalance:
function mintOnSideA(uint256 amount) external {
    // Mint tokens on side A
    mint(msg.sender, amount);
    
    // VULNERABLE: No burn verification
    // Attacker could:
    // 1. Mint on side A
    // 2. Bridge to side B
    // 3. If burn verification weak → Keep tokens on both sides
}

// Detection:
// - Mint/burn asymmetry
// - Delayed verification
// - Insufficient relay validation

---

Phase 4: NFT/Token Exploits

4.1 NFT Marketplace Manipulation

// NFT marketplace bidding:
function bid(uint256 tokenId, uint256 amount) external {
    // VULNERABLE: Race condition in bidding
    
    require(msg.sender == ownerOf(tokenId), "Not owner");
    bids[tokenId] = Bid({bidder: msg.sender, amount: amount});
    
    // Race: Accept bid while owner changes
}

function acceptBid(uint256 tokenId, address bidder) external {
    // VULNERABLE: No validation of bidder validity
    // Could accept old/expired bid
    
    // Issues:
    // - Bid staleness
    // - Price validation
    // - NFT ownership not checked
}

// Detection:
// - No bid expiration
// - No bid cancellation handling
// - Front-running vulnerability

4.2 Token Approval Race Conditions

// ERC20 approval race:
function approve(address spender, uint256 amount) external returns (bool) {
    allowance[msg.sender][spender] = amount;
    return true;
}

// VULNERABLE: Two calls in same block:
// approve(spender, 100) // Allow spend 100
// approve(spender, 0)     // Revoke
// If processed in opposite order → spender can spend

// Detection:
// - Use approve/permit pattern
// - Check for permit() implementation
// - Look for allowance race conditions

---

Phase 5: MEV/Sandwich Attacks

5.1 Sandwich Attack Detection

// AMM DEX swap:
function swap(address tokenIn, address tokenOut, uint256 amountIn) external {
    // Calculate tokens out based on reserves
    uint256 amountOut = getAmountOut(amountIn, tokenIn, tokenOut);
    
    // VULNERABLE: No slippage protection
    // Attacker can:
    // 1. Front-run with buy (push price up)
    // 2. Victim's swap gets worse rate
    // 3. Back-run with sell (profit from difference)
    
    _transfer(tokenIn, msg.sender, address(this), amountIn);
    _transfer(tokenOut, address(this), msg.sender, amountOut);
}

// Detection:
// - No deadline (block.timestamp)
// - No slippage tolerance
// - No minimum amount out
// - Large orders (attractive for sandwiching)

5.2 Flashbots/MEV Analysis

# MEV analysis:

# Check for vulnerable patterns:
# - Large swap without slippage protection
# - Multi-block transactions (frontrun opportunities)
# - Public mempool transactions

# Detection tools:
# - https://mev-inspect.xyz/
# - https://flashbots.noncegev.io/
# - Etherscan mempool analysis

# Novelty:
# - Cross-DEX arbitrage bugs
// - Liquidation race conditions
// - NFT mint sniping

---

Novelty Indicators (PURSUE)

✓ Recent Web3 CVEs (2023-2024):

• Euler Finance exploit (2023) - Donations side effect
• Sentiment Yam V2 (2024) - Price manipulation
• Warp (2024) - Signature replay

✓ Complex logic bugs:

• Multi-contract interactions
• Governance manipulation
• Cross-protocol arbitrage flaws
• Reward mechanism exploits

✓ Novel attack types:

• Read-only reentrancy
• Signature replay across chains
• Oracle manipulation variants
• Liquidation race conditions

---

Known Patterns (AVOID)

✗ Basic reentrancy (The DAO pattern, well-known) ✗ Missing onlyOwner (standard access control) ✗ Simple overflow (Solidity 0.8+ prevents) ✗ Default visibility (well-documented)

---

Analysis Checklist

Smart Contract Code

• Reentrancy patterns identified
• Access control reviewed
• Integer overflow checked
• State order verified (checks-effects-interactions)
• Event emissions validated

DeFi Logic

• Flash loan protections checked
• Oracle validation reviewed
• Slippage protections verified
• Liquidity calculations checked
• Economic incentives analyzed

Bridge/Token

• Signature validation checked
• Mint/burn balance verified
• Cross-chain validation reviewed
• Token approval races checked
• NFT marketplace logic validated

MEV/Mempool

• Transaction ordering analyzed
• Fracntrun vulnerabilities assessed
• Sandwich attack vectors checked
• MEV protection mechanisms verified

---

Quick Reference

Vulnerability	Detection Method	Severity
Reentrancy	External call before state change	Critical
Flash loan	No repayment validation	Critical
Oracle manip.	On-chain price usage	High
Bridge bypass	Signature replay	Critical
Approval race	approve/approve in same block	High
Sandwich	No slippage/delay check	Medium
Read-only reentrancy	View function side effects	High
Integer overflow	Solidity < 0.8 or unsafe math	High
Access control	Missing onlyOwner/roleCheck	Medium

---

Tools for Analysis

# Static analysis tools:
npm install -g slither  # Python-based static analyzer
slither contract.sol

npm install -g mythril  # Symbolic execution
myth analyze contract.sol

# Manual review:
# - Read contract code thoroughly
# - Look for external calls
# - Check state changes
# - Verify access control

# Testing frameworks:
npm install hardhat  # Development environment
npx hardhat test     # Run tests

# Fork testing:
# - Test against mainnet fork
# - Use realistic environment

---

Notes

• Focus on novel logic bugs: Reentrancy variants, economic exploits, complex interactions
• DeFi complexity: Multi-contract, multi-protocol, cross-chain
• Verification: Document contract, vulnerability, exploit steps
• Testnets: Always use testnets (Goerli, Sepolia)
• Responsible disclosure: Web3 bugs can result in fund loss