Security Research DeFi April 12, 2026

What 122 Smart Contract Exploits Taught Us About DeFi Security in 2025

By Atlas Security Research

We analyzed 122 real vulnerability patterns from DeFi exploits and bug bounty reports. Here's what most audits miss — and what you should be looking for right now.

The Numbers Don't Lie

Before we get into patterns, the headline:

  • 122 distinct vulnerability patterns identified across 2024-2025 DeFi exploits
  • 34% classified as CWE-841 (Improper Enforcement of Behavioral Workflow) — the single largest category
  • Integer overflow/underflow vulnerabilities appeared 11 times despite Solidity 0.8+ having built-in overflow protection
  • Every CWE-284 (Access Control) finding was preventable with a single require(msg.sender == owner) check

The patterns aren't exotic. They're the same categories auditors have been flagging for years. The problem isn't that we don't know about them. The problem is that protocols keep shipping without checking.

The Top 5 Vulnerability Patterns

1. Integer Overflow / Underflow — 11 findings

This one is embarrassing. Solidity 0.8+ reverts on overflow. Yet we found 11 cases where:

  • Unchecked math in older Solidity versions still running in production
  • Assembly-level operations bypassing Solidity's built-in protections
  • Token transfer calculations where rounding errors compound over time

The pattern isn't always a dramatic exploit. Sometimes it's a gradual drain — dust amounts leaking on every transaction until the math accumulates into real losses.

2. Flash Loan Price Manipulation — 6 findings

Flash loan attacks are often treated as a niche concern. They shouldn't be. Six separate patterns we found were direct consequences of flash loan price manipulation:

  • Low-liquidity oracle exploitation — a single large flash loan can move the price of an asset enough to trigger liquidations or trigger incorrect settlement
  • TWAP manipulation — time-weighted average price oracles are gameable within the same block if you have enough capital
  • Cross-exchange price arbitrage — draining one pool while another hasn't updated yet

DeFi composability means your protocol's understanding of "price" depends on what's happening across the entire ecosystem, not just your own contracts.

3. Reentrancy — 5 direct, 3 cross-contract variants

Reentrancy is the oldest hack in the book. It's also still happening.

The 2025 variants we're seeing:

  • Cross-function reentrancy — the attacker calls a different function in the same contract, exploiting a stale state between two balances
  • Cross-contract reentrancy — your protocol calls an external contract (like a token) that callbacks into you before state updates
  • Read-only reentrancy — a view function that appears safe but returns stale data because a deeper contract hasn't finished its state transition

The last one is the sneakiest. It affects protocols that read state from other protocols without understanding that the source contract might be mid-reentrancy.

4. Business Logic Errors — 4 findings, infinite damage potential

Here's where audits consistently underperform. Business logic vulnerabilities aren't about missing require statements. They're about the contract doing exactly what the code says — but the code doesn't match what the protocol was supposed to do.

Examples from our research:

  • Incorrect fee calculation — the math was right but the order of operations produced wrong totals
  • Incorrect state update order — state A updated before state B, enabling a window where a second transaction could read stale data
  • Insufficient input validation — values that "should" be impossible weren't explicitly blocked, and someone found a way to make them possible

Business logic bugs are the hardest to find with automated tools. Slither won't catch "you implemented the vesting schedule wrong."

5. Oracle Manipulation via Price Feed Staleness — 4 findings

This one is specific and underappreciated. Many protocols use Chainlink or similar price feeds, assuming "the oracle said it, so it's correct." That's not always true:

  • Stale prices — if the market moves faster than the oracle update frequency, your contract is operating on outdated data
  • Locking prices — a protocol that doesn't enforce a staleness threshold will accept a price that's minutes or hours old as current
  • Liquidation threshold games — if your liquidation logic depends on a price feed, an attacker can manipulate the timing to trigger mass liquidations at favorable prices

The 6th Pattern Nobody Talks About: Frontend Vulnerabilities

We found 8 distinct frontend vulnerability patterns — and most are invisible to smart contract auditors.

The most common:

  • Transaction parameter manipulation — the frontend constructs a transaction, but a malicious site or browser extension modifies the parameters before signing
  • Subdomain takeover — an abandoned subdomain pointing to an external service that an attacker claimed, now serving malicious frontend code under your brand
  • DNS hijacking — the frontend loads from the correct domain, but the DNS has been compromised to point elsewhere
  • UI redressing (clickjacking) — legitimate protocol UI overlaid with attacker-controlled elements that trick users into signing unintended transactions

These don't affect your smart contract code at all. They'll pass any smart contract audit. They'll drain user wallets just as effectively.

The CWE Breakdown

We mapped every pattern to its Common Weakness Enumeration. Here's the distribution:

CWE Name Count
CWE-841Improper Enforcement of Behavioral Workflow34
CWE-190Integer Overflow or Wraparound13
CWE-840Business Logic Errors13
CWE-665Improper Initialization11
CWE-284Improper Access Control6
CWE-682Incorrect Calculation4
CWE-352Cross-Site Request Forgery2

The dominance of CWE-841 is the standout. These are vulnerabilities where the contract technically works correctly — functions execute, math is valid — but the order or conditions under which actions are allowed to occur can be manipulated.

What We Keep Finding in Governance Contracts

Governance attacks were a theme across 8 of our 122 patterns. The common thread:

  • Proposal execution bypass — proposals execute without checking timelock status
  • Parameter manipulation — governance parameters can be modified directly without a proposal
  • Executor privilege escalation — the governance executor can call functions it shouldn't have access to

Many governance contracts have been audited by reputable firms. The auditors checked that individual functions were access-controlled. They didn't always check that the workflow between functions enforced the intended constraints.

Cross-Contract Vulnerabilities: The Hidden Risk of Composability

DeFi is built on composability — your protocol calls my protocol, and we both assume the other one is honest. We found 6 patterns specifically involving cross-contract interactions:

  • Cross-contract reentrancy — Contract A calls Contract B, which calls back into A before A finishes updating its state
  • State inconsistency attacks — two contracts that should maintain synchronized state get out of sync during a complex transaction sequence
  • Inflation/empty pool attacks — a share token's price is manipulated through cross-contract interactions in a way that drains the victim pool

You can't audit your protocol in isolation. If your contracts interact with Uniswap, Aave, Compound, or any external protocol, you need to model those interactions — not just assume external calls are safe.

The Pattern Nobody Wants to Admit: Repeatable Attacks

34 of our 122 patterns were CWE-841 violations. Of those, the majority were repeatable attacks on non-upgradable contracts — bugs that let an attacker drain funds repeatedly until the contract is empty.

This is the worst kind of vulnerability. Unlike a one-time exploit that drains everything at once, a repeatable attack means:

  • The attacker can test and refine their approach
  • Monitoring tools may not catch the first few attempts
  • By the time the pattern is obvious, significant funds are gone
  • The non-upgradable contract means there's no way to patch it — only to wind it down

What Should You Do With This?

If you're building a DeFi protocol:

  1. Don't assume your audit covers you. Many of these patterns are either out of scope for standard audits or require business-logic understanding that automated tools miss.
  2. Focus on workflow enforcement. CWE-841 is your biggest exposure if you're building anything with upgrade paths, governance, or multi-step processes.
  3. Test your oracle assumptions. Price feeds are a surface area that doesn't get enough scrutiny. Test what happens at the edges: stale data, low liquidity, flash-loan-sized transactions.
  4. Your frontend is an attack surface. Subdomain management, DNS configuration, and browser extension interactions are all exploitable paths to user fund loss.
  5. If your contract is non-upgradable, treat any vulnerability as catastrophic. There's no patch, no pause, no recovery.

This research is part of Atlas Agent Suite's ongoing security intelligence effort. We build automated vulnerability scanning and audit tooling for DeFi protocols. If you're building something that touches real money, talk to us before you ship.