Top 10 Smart Contract Vulnerabilities in 2026 (With Real Exploit Examples)

1. Reentrancy

Cumulative losses: $300M+ in 2024-2025

Reentrancy occurs when a contract makes an external call before updating its own state, allowing the called contract to re-enter the original function and repeat the action before the balance is decremented. The Curve Finance exploit (~$70M) and Prisma Finance ($11.6M) both stemmed from this pattern.

Vulnerable:

function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount);
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
    balances[msg.sender] -= amount; // too late
}

Fixed:

function withdraw(uint256 amount) external nonReentrant {
    require(balances[msg.sender] >= amount);
    balances[msg.sender] -= amount; // state updated first
    (bool success, ) = msg.sender.call{value: amount}("");
    require(success);
}

Always follow checks-effects-interactions and use a reentrancy guard. Belt and suspenders.

2. Access Control Flaws

Missing or incorrect access modifiers remain one of the most exploited vulnerability classes. The Nomad Bridge hack ($190M) stemmed from an initialization flaw. In 2024, several protocols lost funds when proxy contracts shipped with unprotected initialize() functions.

Vulnerable:

// Anyone can call initialize and become owner
function initialize(address _token) public {
    owner = msg.sender;
    token = _token;
}

Fixed:

function initialize(address _token) public initializer {
    __Ownable_init(msg.sender);
    token = _token;
}

Every state-changing function needs an explicit access modifier. Use OpenZeppelin's Initializable to prevent double-initialization.

3. Oracle Manipulation

When a protocol uses a single DEX pool's spot price as an oracle, an attacker can distort it within a single transaction using a flash loan. Euler Finance ($197M) was exploited through donation-based oracle manipulation. Multiple lending protocols on L2s were drained in 2024 by manipulating thin-liquidity TWAP oracles.

Vulnerable:

// Spot price from a single pool is trivially manipulable
function getPrice() public view returns (uint256) {
    (uint112 r0, uint112 r1, ) = pair.getReserves();
    return (uint256(r1) * 1e18) / uint256(r0);
}

Fixed:

function getPrice() public view returns (uint256) {
    (, int256 price, , uint256 updatedAt, ) =
        priceFeed.latestRoundData();
    require(price > 0, "Invalid price");
    require(block.timestamp - updatedAt < 3600, "Stale");
    return uint256(price);
}

Use decentralized oracle networks with freshness checks. Never rely on spot prices from a single liquidity pool.

4. Integer Arithmetic Issues

Solidity 0.8+ eliminated overflow/underflow, but precision loss and division-before-multiplication patterns remain widespread — especially in financial calculations involving tokens with different decimal places.

Vulnerable:

// Division before multiplication causes precision loss
function calculateFee(uint256 amount, uint256 fee)
    public pure returns (uint256) {
    return (amount / 10000) * fee; // loses precision
}

Fixed:

function calculateFee(uint256 amount, uint256 fee)
    public pure returns (uint256) {
    return (amount * fee) / 10000; // multiply first
}

Always multiply before dividing. Test with very small and very large values — both matter.

5. Unchecked Return Values

Some ERC-20 tokens (notably USDT) do not revert on failure — they return false. If your contract doesn't check the return value, a failed transfer appears to succeed and your internal accounting diverges from reality.

Vulnerable:

// Ignores return value — USDT returns false
function deposit(uint256 amount) external {
    token.transfer(address(this), amount); // might fail
    balances[msg.sender] += amount;
}

Fixed:

using SafeERC20 for IERC20;

function deposit(uint256 amount) external {
    token.safeTransferFrom(msg.sender, address(this), amount);
    balances[msg.sender] += amount;
}

Use OpenZeppelin's SafeERC20 for every token interaction. There is no reason not to.

6. Flash Loan Attacks

Flash loans give any attacker access to arbitrarily large capital for the cost of gas. This amplifies every other vulnerability on this list. In 2024, multiple vaults were exploited through “first depositor” donation attacks that inflated share prices via flash-loaned capital.

Vulnerable:

// First depositor can inflate share price
function deposit(uint256 assets) external returns (uint256) {
    uint256 shares = totalSupply == 0
        ? assets
        : (assets * totalSupply) / totalAssets();
    _mint(msg.sender, shares);
    token.safeTransferFrom(msg.sender, address(this), assets);
    return shares;
}

Fixed:

constructor() {
    _mint(address(1), 1000); // dead shares prevent inflation
}

function deposit(uint256 assets) external returns (uint256) {
    uint256 shares = (assets * totalSupply) / totalAssets();
    require(shares > 0, "Zero shares");
    _mint(msg.sender, shares);
    token.safeTransferFrom(msg.sender, address(this), assets);
    return shares;
}

Mint “dead shares” on deployment. Add minimum deposit thresholds. Validate that share calculations never round to zero.

7. Front-Running and MEV

Pending transactions are visible in the mempool. MEV bots sandwich DEX trades without slippage protection — buying ahead to drive the price up, then selling after your transaction executes. An estimated $500M+ was extracted from users this way in 2024 alone.

Vulnerable:

// No slippage protection — MEV bots will sandwich this
router.swapExactTokensForTokens(
    amountIn,
    0,             // accepts any output amount
    path,
    msg.sender,
    block.timestamp
);

Fixed:

router.swapExactTokensForTokens(
    amountIn,
    minAmountOut,  // caller specifies minimum
    path,
    msg.sender,
    block.timestamp
);

Always enforce user-specified slippage limits. Consider commit-reveal schemes for sensitive operations.

8. Logic Errors

Logic errors are the hardest to detect with automated tools because the code compiles and passes analysis — it just doesn't do what the developer intended. The Beanstalk exploit ($182M) allowed governance proposals to execute immediately upon quorum with no time delay. An attacker flash-loaned enough tokens to pass and execute a malicious proposal in one transaction.

Vulnerable:

// Executes immediately when quorum is met
function vote(uint256 proposalId) external {
    proposals[proposalId].votes += votingPower[msg.sender];
    if (proposals[proposalId].votes >= quorum) {
        proposals[proposalId].execute(); // no delay
    }
}

Fixed:

function vote(uint256 proposalId) external {
    proposals[proposalId].votes += votingPower[msg.sender];
    if (proposals[proposalId].votes >= quorum) {
        proposals[proposalId].eta =
            block.timestamp + TIMELOCK_DELAY;
    }
}

function execute(uint256 proposalId) external {
    require(block.timestamp >= proposals[proposalId].eta);
    proposals[proposalId].execute();
}

Logic errors require specification-level review and scenario-based testing. Timelocks on governance are non-negotiable.

9. Centralization Risks

Contracts that concentrate excessive power in a single admin address are not decentralized — they are custodial with extra steps. The Ronin Bridge hack ($625M) resulted from compromised validator keys controlled by a single entity. In 2025, multiple protocols suffered admin key compromises through phishing.

Vulnerable:

// Single admin can drain all funds instantly
function emergencyWithdraw(address to) external onlyOwner {
    token.safeTransfer(to, token.balanceOf(address(this)));
}

Fixed:

uint256 public constant TIMELOCK = 48 hours;

function proposeWithdraw(address to) external onlyOwner {
    pendingWithdraw = to;
    withdrawEta = block.timestamp + TIMELOCK;
    emit WithdrawProposed(to, withdrawEta);
}

function executeWithdraw() external onlyOwner {
    require(block.timestamp >= withdrawEta);
    token.safeTransfer(pendingWithdraw,
        token.balanceOf(address(this)));
}

Use multi-sig wallets. Add timelocks to critical operations. Minimize admin privileges. Emit events for every admin action.

10. Upgrade Vulnerabilities

Upgradeable proxies introduce an entire class of bugs that don't exist in immutable contracts. Storage collisions between implementation versions, unprotected upgradeTo functions, and missing storage gaps have all led to bricked or exploited protocols.

Vulnerable:

// No access control on upgradeTo
contract VaultV1 is UUPSUpgradeable {
    function _authorizeUpgrade(address) internal override {
        // anyone can upgrade
    }
}

// No storage gap — V2 variables will corrupt storage
contract BaseVault {
    uint256 public totalDeposits;
    // missing __gap
}

Fixed:

contract VaultV1 is UUPSUpgradeable, OwnableUpgradeable {
    function _authorizeUpgrade(address)
        internal override onlyOwner {}

    uint256[50] private __gap; // reserve storage slots
}

Protect upgrade functions with access control. Include storage gaps in every base contract. Test upgrade paths by deploying V1, upgrading to V2, and verifying all state is preserved.