Common Vulnerabilities & Exploits

Understanding the most common smart contract vulnerabilities is essential for anyone interacting with DeFi. You do not need to be a developer to benefit from this knowledge — recognizing these patterns helps you evaluate protocol risk, understand audit reports, and avoid protocols with dangerous designs. This lesson covers the most frequently exploited vulnerability categories.

1. 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.

Here is the pattern in simplified terms:

1. User requests a withdrawal from a contract.
2. The contract sends the funds to the user's address.
3. The user's address is actually a malicious contract that, upon receiving funds, immediately calls the withdrawal function again.
4. Because the original contract has not yet updated the user's balance (step 2 happened before the balance update), it sends funds again.
5. This loop repeats until the contract is drained.

Prevention: The "checks-effects-interactions" pattern — update state variables before making external calls. Modern Solidity also provides the nonReentrant modifier from OpenZeppelin that prevents a function from being called while it is already executing.

2. Flash Loan Attacks

Flash loans allow anyone to borrow unlimited amounts of cryptocurrency with no collateral, provided the loan is repaid within the same transaction. They are a legitimate DeFi primitive, but they enable attacks that would otherwise require enormous capital:

• Borrow millions via flash loan.
• Use the borrowed funds to manipulate a price oracle or liquidity pool.
• Exploit the manipulated price to drain funds from a vulnerable protocol.
• Repay the flash loan and keep the profits.

Flash loan attacks have been responsible for hundreds of millions in losses. They primarily exploit protocols that rely on spot prices from DEXs as their oracle — because these prices can be temporarily manipulated with large trades.

3. Oracle Manipulation

Oracles feed external data (prices, interest rates, randomness) to smart contracts. If an oracle can be manipulated, the smart contract that relies on it will make decisions based on false data.

Common oracle vulnerabilities include:

• Single-source oracles: Relying on one DEX pool for price data means a flash loan can manipulate the price.
• TWAP manipulation: Time-Weighted Average Price oracles are harder to manipulate but not immune — low-liquidity pools can still be manipulated over short periods.
• Stale data: Oracles that do not update frequently enough can report outdated prices, especially during high-volatility events.

Best practice: Protocols should use decentralized oracle networks like Chainlink, which aggregate data from multiple independent sources, making manipulation prohibitively expensive.

4. Access Control Vulnerabilities

Many smart contracts have admin functions — the ability to pause the contract, change parameters, upgrade logic, or withdraw funds. Access control vulnerabilities occur when these functions are not properly restricted:

• Missing access control: A critical function that should be restricted to the owner/admin is accidentally left public, allowing anyone to call it.
• Centralized admin keys: A single private key controls critical admin functions. If compromised, the attacker gains full control. This is essentially what happened with the Ronin bridge.
• Unrevoked permissions: Temporary permissions granted during development or migration that are never revoked, creating lingering attack surfaces.

5. Integer Overflow and Underflow

Before Solidity 0.8.0, arithmetic operations did not automatically check for overflow or underflow. This meant:

• Overflow: Adding 1 to the maximum uint256 value (2^256 - 1) would wrap around to 0.
• Underflow: Subtracting 1 from 0 would wrap around to the maximum value (2^256 - 1).

Attackers could exploit this to create tokens from nothing or bypass balance checks. Solidity 0.8.0+ automatically reverts on overflow/underflow, but legacy contracts and those using unchecked blocks remain vulnerable.

6. Front-Running and MEV

Front-running occurs when someone observes a pending transaction in the mempool and submits their own transaction first (with a higher gas fee) to profit from the information. MEV (Maximal Extractable Value) is the broader category of value that can be extracted by reordering, inserting, or censoring transactions within a block.

Common MEV attacks include:

• Sandwich attacks: A searcher sees a large DEX swap in the mempool. They place a buy order before it (front-run) and a sell order after it (back-run), profiting from the price impact of the victim's trade.
• Liquidation sniping: Bots monitor lending protocols for positions about to be liquidated and compete to be the first to liquidate them for a profit.
• JIT (Just-In-Time) liquidity: LPs add and remove liquidity around large trades to capture fees without bearing the ongoing risk of providing liquidity.

7. Logic Errors and Business Logic Flaws

Sometimes the code compiles correctly and has no classic vulnerabilities, but the business logic itself is flawed:

• Incorrect reward calculations: Rounding errors, incorrect decimal handling, or flawed interest rate calculations that can be exploited to drain rewards.
• Missing edge cases: The code works for normal transactions but fails for edge cases like zero-amount transfers, self-transfers, or interactions with non-standard tokens.
• Governance attacks: Exploiting governance mechanisms to pass malicious proposals — for example, flash-borrowing governance tokens to gain voting power for a single block.