The OWASP Smart Contract Top 10 (2026): Ten ways contracts lose money

Smart contracts are small programs that hold large amounts of money, cannot be quietly patched, and run in public where anyone can call them. That combination makes their bugs unusually expensive. In early 2026 the OWASP Smart Contract Security project published its Smart Contract Top 10: 2026, a ranked list of the weaknesses that practitioners and incident data say matter most right now. The list was built from 2025 data: 122 deduplicated incidents and about $905.4M in losses that came from smart-contract flaws alone.

This post walks through the ten entries, what changed from last year, and the 2025 incident that best explains each one. It is meant as a map for students who are starting out in smart-contract security, and as a checklist for anyone shipping code on-chain.

How the list is made

OWASP does not rank by dollars lost. Security practitioners answer a survey and rank the categories from 1 to 10; the final order is the average rank, with the median and the number of first-place votes used to break near ties. Incident data from 2025 then shapes which categories exist and how they are defined. So the list reflects what experienced auditors worry about most, checked against what actually happened on-chain.

Two numbers help keep it in proportion. Chainalysis counts more than $3.4B stolen from the whole crypto ecosystem in 2025, and about $1.5B of that came from a single breach of the Bybit exchange. Code flaws in contracts are therefore one slice of the problem, not all of it. Keys, signing workflows and off-chain infrastructure fail too, and as we will see below, those failures often end inside a smart contract anyway.

What changed since 2025

• Business logic moved up to #2. The old "Logic Errors" entry was renamed and promoted. Many 2025 exploits passed every low-level check and still lost money because the economic design was wrong.
• Arithmetic errors (rounding and precision) is new at #7. Integer overflow is now rare in modern Solidity, but rounding in share, interest and AMM math drained several protocols in 2025.
• Proxy and upgradeability is new at #10. Upgradeable contracts add a second, very powerful door: whoever controls the upgrade controls the code.
• Insecure randomness and denial of service left the ranking. OWASP still discusses DoS and griefing under its honourable mentions, together with front-running and MEV, governance attacks, signature-scheme flaws and permit front-running.

Four layers where the risks live

It helps to group the ten entries by where in a system they sit.

Layer 1: keys, roles and upgrades

SC01 Access control. A privileged function is reachable by the wrong caller, or the contract trusts an address it should not. In May 2025, attackers called Cork Protocol's Uniswap v4 hook directly because the hook never checked that the caller was the pool manager, and walked away with about $11M. In March, the Zoth protocol lost $8.4M after the single wallet that controlled its admin functions was compromised and used to upgrade a vault to malicious code. Defence: use audited role libraries such as OpenZeppelin AccessControl, put powerful roles behind multisigs and timelocks rather than one key, check the caller at every hook and callback, and emit an event on every privilege change so monitoring can see it.

SC10 Proxy and upgradeability. Most serious protocols are upgradeable through a proxy, which means a storage slot decides which code runs. In July 2025 the Kinto ecosystem lost about $1.55M to attackers who had found freshly deployed proxies that were never initialised, quietly initialised them with backdoored code, and waited months before using the backdoor. Security researchers tied the same uninitialised-proxy campaign to more than $10M across several chains. Defence: initialise in the same transaction as deployment, lock implementation contracts, use standard UUPS or Transparent proxies, and require a timelock and multisig for every upgrade.

The Bybit breach of February 2025 shows how this layer fails even when the contract code is fine. Attackers tampered with the Safe{Wallet} web interface so that Bybit's signers approved what looked like a routine transfer. The signed transaction was actually a delegatecall that overwrote the Safe proxy's implementation address, handing control of the cold wallet to the attacker. It is an operational attack, but it lands exactly on SC01 and SC10.

Layer 2: protocol logic and math

SC02 Business logic. The code does what it says, but what it says is wrong. In March 2025, Abracadabra lost about $12.9M because a failed deposit followed by a self-liquidation left behind "ghost" collateral that could still be borrowed against. In November, a yETH pool connected to Yearn lost about $9M when highly imbalanced deposits pushed its solver into a state where it minted an absurd number of LP tokens for almost nothing. Defence: write the protocol's economic promises down as invariants ("total withdrawn never exceeds total deposited plus yield") and test them with stateful fuzzing and simulation, not only unit tests.

SC07 Arithmetic errors. Integer division always rounds, and someone gains from every rounding. Balancer V2 lost about $128M in November 2025 when a scaling step that always rounded down was repeated dozens of times inside one batch of swaps. Our companion post, Rounding errors, amplified, takes this case apart in detail. Defence: decide the rounding direction for every operation so it always favours the protocol, and test long sequences of tiny operations, because that is how attackers use it.

SC09 Integer overflow and underflow. Solidity 0.8 reverts on overflow by default, so this risk now lives in unchecked blocks, assembly, custom math libraries and other languages. The largest example of 2025 was on Sui: Cetus lost about $223M in May because an overflow check in a shared math library used the wrong constant, and Move's left shift silently dropped the high bits. A deposit of a single token unit minted a gigantic liquidity position. Defence: avoid unchecked unless a proof or test covers it, learn which operations wrap silently on your chain, and fuzz boundary values in shared libraries.

Layer 3: calls and inputs

SC05 Lack of input validation. Contracts accept parameters, calldata, cross-chain messages and token addresses without checking that they are sane. Cetus also belongs here, since the protocol accepted liquidity values far outside any reasonable range. Ionic Money lost about $6.9M in February 2025 after a fake LBTC token was listed and accepted as collateral without any on-chain check that it was the real asset. Defence: validate every external input, including admin and governance inputs, and write negative tests that prove bad input is rejected.

SC06 Unchecked external calls. Calling another contract hands it control. Arcadia Finance lost about $3.5M in July 2025 because its swap logic would call any router address the user supplied, so the attacker supplied their own contract and used its callbacks to act as a privileged account. Defence: never call user-chosen addresses with your contract's authority, check return values (for tokens, use SafeERC20), and treat every callback as hostile.

SC08 Reentrancy. The oldest bug in the book. In 2016, The DAO lost 3.6M ETH because it sent ether before updating balances, which led to the Ethereum hard fork. Nine years later, GMX V1 lost about $42M in July 2025 through the same pattern: a refund handed control to an attacker contract before the state was updated, and the attacker re-entered to distort GLP pricing. The vulnerable code had been introduced in 2022 by an unaudited patch. Defence: follow checks-effects-interactions, add ReentrancyGuard to functions that move value, and review cross-function and cross-contract paths, not just single functions.

// Checks-effects-interactions: update state before handing control away
function withdraw(uint256 amount) external nonReentrant {
    require(balance[msg.sender] >= amount, "insufficient");   // check
    balance[msg.sender] -= amount;                            // effect
    (bool ok, ) = msg.sender.call{value: amount}("");         // interaction
    require(ok, "transfer failed");
}

Layer 4: market data and capital

SC03 Price oracle manipulation. A contract trusts a price that an attacker can move. The NGP token on BNB Chain lost about $2M in September 2025 because its price came straight from one pair's reserves, which a flash-loan swap skewed. In the GMX case above, manipulating the average short price was what turned reentrancy into profit. Defence: use aggregated or time-weighted prices, reject stale or outlying values, avoid thin pools as price sources, and pause sensitive actions when data looks wrong.

SC04 Flash-loan-facilitated attacks. Flash loans let anyone borrow millions with no collateral, as long as they repay in the same transaction. They are rarely the bug itself; they are the multiplier that turns a small rounding or pricing flaw into a large drain. Bunni lost about $8.4M in September 2025 this way, and zkLend about $9.5M in February. Defence: assume attackers have unlimited capital for one transaction, cap how much state can change per call or per block, and include flash-loan scenarios in tests and audits.

Quick reference

Three lessons from reading the list as a whole

1. Old bugs return in new places. Reentrancy drained The DAO in 2016 and GMX in 2025. Parity's 2017 multisig freeze, where someone could initialise and then destroy a shared library contract and lock about 513,000 ETH, has the same root as the 2025 uninitialised-proxy campaign: a contract that anyone could claim before its owner did.
2. Exploits chain. Almost no 2025 incident fits one box. GMX combined reentrancy with price manipulation; Cetus combined bad input with an overflow; Bunni combined rounding with a flash loan. Audits and tests need to think in sequences, not single functions.
3. The code around the code matters. Several of the largest losses started with a key, a deployer wallet, a listing process or a web interface. Good contract code still needs good operations.

Going further

If you are new to the field, read the OWASP entry for each category, then read one post-mortem from the sources below and try to reproduce the bug in a local test with Foundry. Writing the exploit yourself is the fastest way to recognise the pattern in someone else's code. Members of the Blockchainist lab who want to go deeper can pick one of these incidents for an incident-analysis post on this site.