Common Smart Contract Vulnerabilities

Smart contracts are immutable programs deployed on blockchains that autonomously manage billions of dollars in digital assets. Their immutability, while a feature for trust, becomes a liability when vulnerabilities exist in deployed code. Since 2016, smart contract exploits have resulted in over $6 billion in losses across the DeFi ecosystem. Understanding these vulnerabilities is essential for developers, auditors, and investors alike.

This guide catalogs the most prevalent and damaging vulnerability classes in smart contract development, with real-world examples and concrete mitigation strategies.

Reentrancy Attacks

Reentrancy is the most historically significant smart contract vulnerability. It occurs when a contract makes an external call to another contract before updating its own state, allowing the called contract to re-enter the original function and repeat actions such as withdrawals.

The most notorious reentrancy exploit was The DAO hack in June 2016, which drained approximately $60 million in ETH from a decentralized investment fund. The attacker exploited a recursive call vulnerability in the withdrawal function, repeatedly withdrawing funds before the contract's balance was updated. This incident was so severe that it led to the Ethereum hard fork that created Ethereum Classic.

How Reentrancy Works

A vulnerable contract typically follows this pattern: it checks the caller's balance, sends ETH via a low-level call, and then updates the balance. The problem arises because the ETH transfer triggers the recipient's receive() or fallback() function, which can call back into the original contract's withdrawal function before the balance has been set to zero.

Mitigation: Checks-Effects-Interactions Pattern

The standard defense is the checks-effects-interactions pattern. Structure every function so that you first validate all conditions (checks), then update all state variables (effects), and only then make external calls (interactions). Additionally, use a reentrancy guard (mutex lock) to prevent recursive calls. OpenZeppelin's ReentrancyGuard contract provides a battle-tested implementation.

Integer Overflow and Underflow

Prior to Solidity 0.8.0, arithmetic operations did not automatically check for overflow or underflow. An unsigned integer at its maximum value (2^256 - 1) would wrap around to zero when incremented, and a zero value would wrap to the maximum when decremented. Attackers exploited this to mint tokens, inflate balances, or bypass critical checks.

The Beauty Chain (BEC) token exploit in April 2018 demonstrated this class of vulnerability. An integer overflow in the batchTransfer function allowed an attacker to generate an astronomically large number of tokens from nothing, crashing the token's market value.

Mitigation

• Use Solidity 0.8.0 or later, which includes built-in overflow and underflow checks that revert on arithmetic errors.
• For contracts on earlier Solidity versions, use OpenZeppelin's SafeMath library, which wraps all arithmetic operations with overflow checks.
• Be cautious with unchecked blocks in Solidity 0.8+, which disable these protections for gas optimization. Only use them when overflow is mathematically impossible.

Access Control Issues

Improper access control allows unauthorized users to execute privileged functions such as minting tokens, pausing contracts, upgrading logic, or withdrawing funds. These vulnerabilities arise from missing modifiers, incorrectly implemented role checks, or unprotected initialization functions.

The Parity Wallet hack (November 2017) is a textbook example. An unprotected initWallet function in the library contract allowed anyone to claim ownership of the multi-signature wallet library. The attacker then called selfdestruct, permanently freezing approximately $150 million in ETH across 587 wallets.

Mitigation

• Use OpenZeppelin's AccessControl or Ownable contracts for role-based permissions.
• Ensure all administrative functions have appropriate access modifiers.
• Protect initializer functions with initializer modifiers that prevent re-execution.
• Implement multi-signature requirements for critical operations.

Front-Running and MEV

Front-running exploits the transparency of blockchain mempools. When a user submits a profitable transaction, miners or bots can observe it in the pending transaction pool, copy the strategy, and submit their own transaction with a higher gas price to be executed first. This practice is part of the broader category of Maximal Extractable Value (MEV).

Common front-running targets include DEX trades (sandwich attacks), token launches, NFT mints, and liquidations. Sandwich attacks alone extracted over $400 million from Ethereum users in 2023.

Mitigation

• Implement commit-reveal schemes for sensitive operations.
• Use private transaction pools such as Flashbots Protect.
• Set appropriate slippage tolerances in DEX transactions.
• Use time-weighted average prices (TWAPs) instead of spot prices.

Oracle Manipulation

DeFi protocols that rely on on-chain price oracles are vulnerable to manipulation. Attackers can use flash loans to temporarily distort asset prices on a DEX, then exploit protocols that reference those manipulated prices for lending, liquidations, or synthetic asset issuance.

The Mango Markets exploit (October 2022) resulted in a $114 million loss when the attacker manipulated the price of the MNGO token on the platform's oracle, inflating their collateral value and draining the protocol's treasury through massive borrows.

Mitigation

• Use decentralized oracle networks such as Chainlink that aggregate data from multiple off-chain sources.
• Implement TWAP oracles that average prices over time, making single-block manipulation impractical.
• Set price deviation thresholds and circuit breakers that pause operations during abnormal price movements.
• Never rely on a single liquidity pool as a price source.

Flash Loan Attacks

Flash loans allow users to borrow unlimited capital with zero collateral, provided the loan is repaid within a single transaction. While legitimate uses exist (arbitrage, collateral swaps), attackers combine flash loans with other vulnerabilities to amplify exploits. Flash loans have been a component in dozens of major DeFi exploits totaling billions in losses.

A typical flash loan attack involves borrowing a large amount, using it to manipulate a price oracle or exploit a protocol vulnerability, extracting profit, repaying the loan, and keeping the difference, all within a single atomic transaction.

Delegatecall Vulnerabilities

delegatecall executes code from another contract in the context of the calling contract, preserving the caller's storage, msg.sender, and msg.value. This is essential for proxy patterns and upgradeable contracts but introduces severe risks if misused.

Storage Collision

When using delegatecall with proxy contracts, the implementation and proxy contracts must maintain identical storage layouts. If the implementation contract declares variables in a different order or inserts new variables, it will read and write to incorrect storage slots in the proxy, potentially corrupting critical state such as owner addresses or balances.

Mitigation

• Use established proxy patterns: Transparent Proxy, UUPS, or Diamond (EIP-2535).
• Never change the order of existing storage variables in upgradeable contracts.
• Use storage gaps (reserved slots) to allow future variable additions.
• Use OpenZeppelin's upgradeable contract libraries, which handle storage layout safely.

tx.origin vs msg.sender

Using tx.origin for authorization checks is dangerous because it returns the original externally owned account (EOA) that initiated the transaction, not the immediate caller. An attacker can deploy a malicious contract that, when interacted with by the victim, calls the vulnerable contract. The tx.origin check will pass because it resolves to the victim's address, not the attacker's contract.

Always use msg.sender for authentication. tx.origin should never be used for authorization purposes. The only safe use of tx.origin is to verify that msg.sender == tx.origin, confirming the caller is an EOA rather than a contract.

Unchecked External Calls

Low-level calls (call, send, delegatecall) in Solidity return a boolean indicating success or failure rather than reverting on failure. If the return value is not checked, the contract may continue execution as if the call succeeded, leading to inconsistent state. For example, a contract that sends ETH via call without checking the return value may update a user's balance to zero even though the transfer actually failed.

Mitigation

• Always check return values of low-level calls and revert on failure.
• Prefer transfer or OpenZeppelin's Address.sendValue for simple ETH transfers.
• Use OpenZeppelin's SafeERC20 library for token transfers, which handles non-standard return values.

Denial of Service Patterns

Denial of service (DoS) vulnerabilities prevent legitimate users from interacting with a contract. Common patterns include:

• Unbounded loops: Iterating over arrays that grow without limit, eventually exceeding the block gas limit.
• Unexpected reverts: A function that sends ETH to multiple recipients in a loop can be blocked if one recipient is a contract that reverts on receive.
• Block gas limit: Operations that require more gas than a single block allows become permanently unexecutable.

Mitigation

• Use pull-over-push payment patterns: let users withdraw funds rather than pushing payments to them.
• Implement pagination for operations that process variable-length arrays.
• Set upper bounds on loop iterations and array sizes.

Best Practices for Secure Smart Contract Development