The OWASP Smart Contract Top 10: 2026 just dropped, and it's the most data-driven edition yet — built on 122 deduplicated incidents from 2025 totaling $905.4 million in smart contract losses alone. If you're building, auditing, or investing in DeFi, this is your threat landscape.
I've mapped every category to real-world exploits so you can see exactly how these vulnerabilities play out in production.
SC01: Access Control Vulnerabilities — Still #1, Still Devastating
What it is: Unauthorized access to privileged functions or critical protocol state. Privilege misconfiguration, upgrade authority concentration, insufficient separation of duties.
Why it's #1: Access control bugs are the easiest to exploit and the hardest to recover from. Once an attacker gains admin access, game over.
Real-World Example: Bybit — $1.5B (February 2025)
The largest crypto theft in history wasn't a smart contract bug — it was a supply chain attack on Safe{Wallet}'s frontend infrastructure that manipulated the signing interface for Bybit's multisig. The attackers compromised the build/deploy pipeline, injecting malicious code that altered transaction data presented to signers. All signers approved what appeared legitimate while actually authorizing a delegatecall to attacker-controlled code.
Lesson: Access control extends far beyond onlyOwner modifiers. Your multisig is only as secure as the interface your signers use to verify transactions. Hardware wallet "blind signing" made the UI manipulation invisible.
Defense Patterns
- Implement role-based access with time-locked operations
- Require multiple independent verification channels for high-value transactions
- Use transparent signing interfaces that show raw calldata
- Separate operational keys from upgrade/admin keys
SC02: Business Logic Vulnerabilities — Up From #4
What it is: Design-level flaws in protocol economics that break intended rules, enabling value extraction even when low-level checks appear correct.
Why it moved up: Complex DeFi composability means more logic = more attack surface. These bugs can't be caught by static analysis alone.
Real-World Example: Aave $50M Slippage Incident (March 2026)
A trader swapped $50.4M USDT for AAVE tokens through the Aave interface, receiving only ~$36K worth of AAVE. The SushiSwap AAVE-USDT pool had nowhere near enough liquidity. MEV bots extracted ~$44M in sandwich attacks. Both Aave's UI and CoW Swap displayed slippage warnings — but the protocol didn't enforce a hard cap on slippage for retail-scale transactions.
Lesson: Warning users isn't a security control. Business logic should enforce sane bounds even when users explicitly consent to dangerous parameters. "Are you sure?" is not a guardrail.
Defense Patterns
- Enforce protocol-level slippage limits, not just UI warnings
- Model adversarial economic scenarios during design (game theory)
- Test with invariant fuzzing that explores unexpected interaction sequences
- Implement circuit breakers for anomalous trade sizes
SC03: Price Oracle Manipulation
What it is: Manipulable oracles skewing prices to enable undercollateralized borrowing, unfair liquidations, and mispriced swaps.
Real-World Example: sDOLA/Llamalend — $240K (2025)
An attacker manipulated a thin on-chain oracle feeding the sDOLA lending market on Curve's Llamalend, triggering artificial liquidations and extracting ~$240K. The oracle relied on a single AMM pool with insufficient liquidity depth.
Lesson: Single-source oracles on thin pools are a ticking time bomb. TWAP doesn't save you if the observation window is shorter than the attacker's capital patience.
Defense Patterns
- Use decentralized oracle networks (Chainlink, Pyth) with multiple data sources
- Implement TWAP with sufficiently long windows (≥30 minutes)
- Add deviation checks: reject price updates that move >X% in one block
- Design oracle failsafes: pause operations if feeds go stale
SC04: Flash Loan–Facilitated Attacks
What it is: Using uncollateralized flash loans to amplify small bugs into catastrophic drains within a single transaction.
Real-World Example: Makina — $4.13M (January 2026)
Makina was hit with a flash loan that amplified an oracle manipulation vulnerability. The attacker borrowed a massive amount via flash loan, used it to skew a pool price, took out undercollateralized loans against the manipulated price, then repaid the flash loan — all in one atomic transaction.
Lesson: Flash loans are the "force multiplier" of DeFi exploits. Any bug that exists at sufficient scale becomes exploitable when capital constraints are removed.
Defense Patterns
- Implement same-block reentrancy guards across dependent operations
- Add minimum holding periods for collateral deposits before borrowing
- Use flash-loan-resistant oracles (multi-block TWAP)
- Consider transaction origin checks (though these have composability tradeoffs)
SC05: Lack of Input Validation
What it is: Missing validation of external inputs that allows unsafe parameters to reach core logic, corrupting state or enabling fund loss.
Real-World Example: YO Protocol — $3.71M (January 2026)
YO Protocol was drained because a misconfigured slippage parameter allowed swaps to execute at arbitrarily bad rates. The function accepted any value for slippage tolerance without bounds checking, and the deployment used a dangerously permissive default.
Lesson: Every external input is an attack vector. "The frontend validates it" is not a valid security argument — attackers don't use your frontend.
Defense Patterns
- Validate all inputs at the contract level, not just the UI
- Set explicit bounds for numeric parameters (min/max slippage, amounts, deadlines)
- Use
requirestatements with descriptive error messages - Implement allowlists for address parameters where applicable
SC06: Unchecked External Calls
What it is: Unsafe interactions with external contracts where failures, reverts, or callbacks aren't safely handled.
Real-World Example: CrossCurve Bridge — $3M (February 2026)
CrossCurve lost $3M across Ethereum and Arbitrum because of a missing access control on Axelar's expressExecute function. External calls to the bridge's settlement logic weren't properly guarded, allowing anyone to call the express execution path and redirect funds.
Lesson: Every external call is a trust boundary. If you can't verify who's calling and what state they're passing, assume the worst.
Defense Patterns
- Check return values of all external calls (don't ignore
bool success) - Implement the Checks-Effects-Interactions pattern religiously
- Use
try/catchfor calls that might revert - Never trust caller identity from
tx.origin
SC07: Arithmetic Errors
What it is: Bugs in integer math, scaling, and rounding — especially in share calculations, interest accrual, and AMM formulas.
Real-World Example: First-Depositor Inflation Attacks (Ongoing)
The classic ERC-4626 vault inflation attack exploits rounding in share calculation: attacker deposits 1 wei, then front-runs the next depositor by directly transferring tokens to inflate totalAssets. The victim's deposit rounds down to 0 shares. This pattern has been exploited across multiple protocols.
Lesson: Rounding errors in integer division are silent killers. They're invisible in tests with reasonable values but devastating at extreme scales.
Defense Patterns
- Use virtual shares/assets offset in vault implementations (OpenZeppelin's approach)
- Implement minimum deposit thresholds
- Always round against the user in share calculations (round down on deposit, round up on withdrawal)
- Fuzz test with extreme values: 1 wei,
type(uint256).max, and everything in between
SC08: Reentrancy Attacks — Down to #8 But Not Gone
What it is: External calls reentering vulnerable functions before state updates complete, allowing repeated withdrawals from stale state.
Real-World Example: Solv Protocol ERC-3525 Reentrancy — $2.7M (2026)
Solv Protocol used ERC-3525 semi-fungible tokens with a callback mechanism during transfers. An attacker exploited the callback to re-enter the minting function before the transfer state was finalized, creating duplicate token positions worth $2.7M.
Lesson: New token standards (ERC-3525, ERC-1155, Token-2022 transfer hooks) introduce new callback surfaces. "We don't use ERC-721 so reentrancy doesn't apply" is a dangerous assumption.
Defense Patterns
- Follow Checks-Effects-Interactions in every function
- Use OpenZeppelin's
ReentrancyGuard(nonReentrantmodifier) - Be especially cautious with tokens that have transfer callbacks
- Audit all external calls in the context of read-only reentrancy too
SC09: Integer Overflow and Underflow
What it is: Arithmetic where values wrap around (overflow/underflow) on platforms without built-in checks, breaking invariants and enabling drains.
Real-World Example: TrueBit — $26.2M (January 2026)
TrueBit's 2021-era contract used Solidity 0.5.x without SafeMath. An unprotected addition in getPurchasePrice allowed an attacker to pass an extremely large input that overflowed to zero, minting massive quantities of TRU tokens at zero cost and draining the bonding curve.
Lesson: Legacy contracts are ticking time bombs. Solidity 0.8+ has built-in overflow checks, but thousands of pre-0.8 contracts still hold hundreds of millions. "It's old code, nobody looks at it" is exactly why attackers look at it.
Defense Patterns
- Use Solidity ≥0.8.x for built-in overflow protection
- For older contracts: migrate or add SafeMath wrappers
- Audit
unchecked {}blocks in 0.8+ code — they deliberately bypass protections - For Solana/Rust: use
checked_add,checked_mulinstead of raw arithmetic
SC10: Proxy & Upgradeability Vulnerabilities
What it is: Misconfigured proxy, initialization, and upgrade mechanisms enabling implementation takeover or state reinitialization.
Real-World Example: FOOMCASH zkSNARK Verification Key — $2.26M (2025-2026)
FOOMCASH used upgradeable proxy contracts for their zkSNARK verifier. A misconfigured verification key allowed forged proofs to pass validation. The upgrade mechanism lacked proper access controls and time-locks, meaning the vulnerable implementation was deployed without adequate review.
Lesson: Upgradeable contracts multiply your attack surface. Every upgrade is a potential supply chain attack. Every initialization function is a potential reinitialization attack.
Defense Patterns
- Use
initializermodifiers and disable initializers in implementation contracts - Implement timelock + multisig for all upgrades
- Store upgrade history on-chain for transparency
- Consider immutable contracts where possible — upgradability is a feature AND a vulnerability
The Meta-Lesson: Compound Vulnerabilities
The 2026 OWASP report emphasizes that modern attacks rarely exploit a single vulnerability class. The typical attack chain looks like:
- Flash loan (SC04) provides capital
- Oracle manipulation (SC03) skews prices
- Business logic flaw (SC02) allows undercollateralized position
- Unchecked external call (SC06) enables extraction
This is why checklist-style audits fail. Security requires threat modeling that considers how vulnerabilities compose.
What Changed From 2025?
| Category | 2025 Rank | 2026 Rank | Movement |
|---|---|---|---|
| Access Control | #1 | #1 | — |
| Business Logic | #4 | #2 | ⬆️ +2 |
| Oracle Manipulation | #3 | #3 | — |
| Flash Loan Attacks | #6 | #4 | ⬆️ +2 |
| Input Validation | #5 | #5 | — |
| Unchecked External Calls | #7 | #6 | ⬆️ +1 |
| Arithmetic Errors | NEW | #7 | 🆕 |
| Reentrancy | #2 | #8 | ⬇️ -6 |
| Integer Overflow | #9 | #9 | — |
| Proxy/Upgradeability | NEW | #10 | 🆕 |
The biggest story: Reentrancy dropped from #2 to #8. Not because it's solved, but because other attack vectors (business logic, flash loans) have grown more impactful. The rise of business logic bugs to #2 reflects DeFi's increasing complexity.
Actionable Takeaways for Developers
Start with threat modeling, not code review. Map your trust boundaries, privileged roles, and economic assumptions before writing a single test.
Invariant fuzz testing is non-negotiable. Tools like Foundry, Echidna, and Medusa find bugs that unit tests miss by exploring state spaces you didn't imagine.
Audit your dependencies. The OWASP honorable mentions include supply chain attacks and cross-chain MEV — threats that live outside your contract code.
Assume composability is adversarial. Any function that can be called by another contract can be called by an attacker's contract. Design accordingly.
Legacy code is high-risk code. If you have pre-0.8 Solidity or unaudited contracts holding value, prioritize migration or comprehensive audit NOW.
The full OWASP Smart Contract Top 10: 2026 is available at scs.owasp.org/sctop10. It's maintained by the OWASP community with incident data aggregated by CredShields.
Building on Solana or EVM? I write about smart contract security, vulnerability research, and audit tooling. Follow for weekly deep dives.
Top comments (0)