OWASP Smart Contract Top 10 2026: Risks and Defences

The OWASP Smart Contract Top 10:2026 changes what auditors, protocol teams and risk reviewers should look at first, and many security programmes still work from the 2025 order. The 2026 edition keeps access control at the top, promotes business logic flaws to second, lifts flash loan attacks from seventh to fourth, and adds new entries for arithmetic precision and proxy upgradeability while dropping insecure randomness and denial of service. This guide walks through each of the ten risks with the defences, tests and monitoring that address it, maps the list to control frameworks, and shows how to use it in reviews without treating it as a complete checklist. It is written for smart contract developers, auditors, security reviewers and the risk and compliance teams who oversee protocols or crypto-asset businesses. For the wider development lifecycle, see the Smart Contract Security Guide.

Key takeaways

The 2026 list is forward-looking. OWASP built the order from 2025 incident data (122 deduplicated smart contract incidents with about 905.4 million US dollars in smart-contract-only losses, by its count) and a practitioner survey, aiming at the risks that will matter in the coming year.
Privilege and design dominate. Access control (SC01) and business logic (SC02) lead because they cause large losses even when low-level code is correct and audited.
Several risks are multipliers, not root causes. Flash loans (SC04) and oracle manipulation (SC03) turn small flaws in logic or arithmetic into large drains within one transaction.
Upgradeability is now its own category. SC10 covers uninitialised proxies, unguarded upgrades and storage collisions, which OWASP links to a 2025 campaign that cost more than 10 million US dollars across protocols.
The list covers contract code only. Key theft, signer interface compromise and phishing sit outside it, and caused some of the largest web3 losses; plan for them separately.

The 2026 list at a glance

ID	Risk (OWASP name)	2025 position	In one line
SC01:2026	Access Control Vulnerabilities	SC01	Unauthorised parties reach privileged functions or critical state, often through admin, governance or upgrade paths
SC02:2026	Business Logic Vulnerabilities	SC03 (Logic Errors)	Design flaws in lending, AMM, reward or governance rules break intended behaviour even when low-level checks pass
SC03:2026	Price Oracle Manipulation	SC02	Skewed reference prices enable bad loans, unfair liquidations or mispriced swaps
SC04:2026	Flash Loan-Facilitated Attacks	SC07 (Flash Loan Attacks)	Large uncollateralised loans amplify small bugs into large losses in a single transaction
SC05:2026	Lack of Input Validation	SC04	Unchecked user, admin or cross-chain inputs corrupt state or allow direct loss
SC06:2026	Unchecked External Calls	SC06	Failures or callbacks from external calls go unhandled, leaving inconsistent state or enabling reentrancy
SC07:2026	Arithmetic Errors (Rounding and Precision)	New	Precision and rounding bugs in share, interest and AMM maths that can be exploited repeatedly
SC08:2026	Reentrancy Attacks	SC05 (Reentrancy)	Functions are re-entered before state updates, allowing repeated withdrawals
SC09:2026	Integer Overflow and Underflow	SC08	Values wrap without robust checks, breaking invariants
SC10:2026	Proxy and Upgradeability Vulnerabilities	New	Weakly governed proxies, initialisation or upgrade paths let attackers take over implementations

OWASP writes the fourth and tenth names with an en dash and an ampersand respectively; this page uses a hyphen and "and". Two 2025 entries left the list: Insecure Randomness (2025 SC09) and Denial of Service (2025 SC10). A related item, DoS and griefing via gas, loops and state bloat, is listed as an honourable mention. OWASP does not explain the removals, so do not drop randomness or gas griefing checks from reviews: they still apply to games, lotteries and anything that loops over user-controlled data.

Privilege and design risks: SC01, SC02 and SC10

SC01 Access Control Vulnerabilities

OWASP widens access control beyond a missing onlyOwner to governance contracts, multisigs, guardians, proxy admins and cross-chain routers. Its vulnerable patterns are missing modifiers or role checks, wrong assumptions about msg.sender (through delegatecall, meta-transactions or hooks), unprotected initialisation and privilege confusion across modules. Named 2025 incidents include Balancer V2 (about 128 million US dollars, a sender check against a user-supplied field chained with a rounding flaw), Zoth (8.4 million, a compromised deployer key used to upgrade a vault proxy) and Cork Protocol (11 to 12 million, hook callbacks without a pool manager check).

Defence: role-based access with one role per power, multisig and timelock holders rather than single keys, two-step ownership transfer, and negative tests for every privileged function. See the Smart Contract Access Control Guide.

SC02 Business Logic Vulnerabilities

The code does what it says, but what it says is exploitable: invariant violations between modules (collateral against debt, supply against backing), reward and fee errors, bypassable eligibility checks, and state machines that reach inconsistent states. OWASP cites Abracadabra in March 2025 (about 12.9 million US dollars, positions erased without removing collateral, leaving "ghost" collateral to borrow against) and the Yearn yETH pool in November 2025 (about 9 million, an invariant collapse that allowed unbacked minting).

Defence: write the economic invariants down before code, express them as tests and fuzzing properties, use formal verification for accounting paths, model adversarial behaviour rather than intended use, and launch new strategies behind caps that rise only after validation.

SC10 Proxy and Upgradeability Vulnerabilities

New in 2026. Covers Transparent, UUPS, Beacon and custom router patterns (and non-EVM analogues such as Solana program upgrades): unguarded upgrade functions, no sanity checks on the new implementation, unguarded or repeatable initialisers, storage slot collisions, and proxies left uninitialised for an attacker to claim. OWASP names Kinto Protocol (July 2025, 1.55 million US dollars, proxies initialised by the attacker with dormant backdoors activated months later) and a wider 2025 campaign that scanned for new uninitialised ERC1967 proxies across EVM chains.

Defence: use maintained proxy libraries, initialise in the same transaction as deployment, lock implementation contracts, hold upgrade roles in governance or multisig behind a timelock, check storage layout on every upgrade and keep an upgrade runbook. See the Smart Contract Upgradeability and Proxy Security Guide.

Economic manipulation risks: SC03, SC04 and SC07

These three often appear together in one exploit: a flash loan supplies the capital, an oracle or pool is pushed out of line, and a rounding or accounting flaw turns that distortion into profit.

Risk	Attack shape (defensive summary)	Primary defences	OWASP 2025 examples
SC03 Price Oracle Manipulation	Spot price moved within one block, short TWAP windows pushed in thin liquidity, stale or stuck feeds, weak outlier rejection	Several sources with median and deviation limits, long enough TWAP, staleness and round completeness checks, avoid illiquid pools, conservative loan-to-value, halt on suspicious data	NGP Token (about 2 million, price from DEX pair reserves); GMX (42 million, reentrancy with price manipulation as an enabler)
SC04 Flash Loan-Facilitated Attacks	Borrow, manipulate state, extract and repay in a single transaction	Design as if attackers have unlimited temporary capital, rate-limit sensitive actions per block or epoch, cap exposure per interaction, fuzz multi-call sequences, fix the root cause the loan amplifies	Bunni (8.4 million); zkLend (9.5 million)
SC07 Arithmetic Errors	Truncation, scaling and unit conversion errors repeated many times; zero-supply and first-depositor edge cases in vaults	Documented and tested rounding direction (round in the protocol's favour), explicit zero-supply handling, reviewed fixed-point libraries, invariants on share value, fuzz and differential testing	zkLend (rounding down in mint); Bunni (withdrawal rounding)

Note that OWASP lists the same two incidents under SC04 and SC07: the flash loan was the multiplier, the rounding flaw the root cause. Record both in findings so the fix targets the arithmetic and the monitoring targets the loan pattern.

Code-level risks: SC05, SC06, SC08 and SC09

SC05 Lack of Input Validation: validate every parameter at the boundary, including those from admins and cross-chain messages: zero addresses, array lengths, ranges and units, and whether a token or target address is one the protocol expects. Admin inputs matter because a fat-fingered parameter can be as damaging as an attack.
SC06 Unchecked External Calls: check the return value of low-level calls, use safe wrappers for token transfers that do not return a boolean, and treat every external call as a point where control passes to untrusted code.
SC08 Reentrancy Attacks: follow the Checks-Effects-Interactions pattern, which the Solidity documentation describes as making interactions with other contracts the very last step in any function, and add a reentrancy guard on functions that move value. Consider cross-function and read-only reentrancy, where another function or a view reads state mid-update.
SC09 Integer Overflow and Underflow: Solidity 0.8 and later revert on overflow by default, so the remaining risk sits in unchecked blocks, inline assembly, older compiler versions, downcasting between integer sizes, and non-Solidity languages. Review each unchecked block with a written justification.

Using the Top 10 in a review programme

The Top 10 is an awareness list. OWASP's Smart Contract Security project also publishes a verification standard (SCSVS), a weakness enumeration (SCWE), a testing guide (SCSTG) and a checklist, which are better suited to audit scoping and evidence. Use the Top 10 to set priorities and the standard to test.

Classify the system: lending, AMM, vault, bridge, NFT, governance. Business logic, oracle and flash loan risks weigh most on lending and AMMs; SC10 on anything upgradeable; SC01 on everything.
Write the specification and invariants first: roles and powers for SC01, economic invariants for SC02 and SC07, trusted price sources and freshness limits for SC03.
Automate the cheap checks in CI: static analysis for missing modifiers, unchecked calls, reentrancy shapes and tx.origin use; compile with a current compiler; storage layout comparison on every upgrade.
Fuzz and verify the expensive ones: property-based and invariant fuzzing with large temporary balances to model SC04; formal verification on accounting paths.
External review: audit, then contest or bounty for higher value systems. Ask auditors to report findings against SC IDs so they can be tracked. See the Smart Contract Audit Readiness and Choosing an Auditor Guide.
Guarded launch: caps, rate limits and a tested pause path before full value is at risk; raise limits in stages.
Monitor and rehearse: on-chain alerts per risk (below) and a response playbook rehearsed at least once. See the Web3 Incident Response Playbook.

Decision guidance

Small team, simple token or NFT: SC01, SC05, SC06 and SC09 cover most of the realistic risk. Prefer immutable contracts with no owner, and avoid upgradeability you do not need.
DeFi protocol holding user funds: all ten apply; SC02, SC03, SC04 and SC07 need economic modelling that a code-only audit will not provide.
Upgradeable system: SC10 and SC01 must be reviewed together on every release, not only at first audit.
Regulated crypto-asset business: add key custody, signer process and front-end integrity, which the Top 10 does not cover. See the MiCA and DORA for Crypto-Asset Service Providers Guide.

Detection and measurement

Risk	What to monitor on chain
SC01, SC10	Role, ownership, proxy admin and implementation change events; privileged calls from unexpected addresses
SC02, SC07	Invariant checks (total assets against total shares, collateral against debt) evaluated per block; unusual share price moves
SC03	Deviation between protocol prices and reference markets; stale feed updates
SC04	Transactions that borrow and repay large flash loans while touching your contracts
SC06, SC08	Repeated calls into value-moving functions within one transaction; failed external calls

Metric: coverage of SC IDs in the threat model and test plan: every applicable risk has at least one test or property, target 100 per cent.
Metric: invariant properties under continuous fuzzing: count and run time per release, trending up.
Metric: open high or critical findings by SC ID at launch: zero.
Metric: mean time from alert to pause or cancel decision: measured in drills, well inside any timelock delay.
Metric: value deployed above audited caps: zero until staged limits are passed.

Framework mapping

Programme activity	Top 10 risks	NIST SP 800-53 Rev 5	NIST CSF 2.0
Secure design and invariants	SC02, SC03, SC07	SA-8 Security and Privacy Engineering Principles	PR.PS-06
Access and privilege control	SC01, SC10	AC-6 Least Privilege, AC-5 Separation of Duties	PR.AA-05
Input handling	SC05	SI-10 Information Input Validation	PR.PS-06
Testing, fuzzing and audit	All	SA-11 Developer Testing and Evaluation, SA-11(8) Dynamic Code Analysis, CA-8 Penetration Testing	ID.RA-01
Upgrades and parameter changes	SC10, SC01	CM-3 Configuration Change Control	PR.PS-01
On-chain monitoring	All	SI-4 System Monitoring	DE.CM-09, DE.AE-02
Risk assessment and prioritisation	All	RA-3 Risk Assessment	ID.RA-01

Common failure patterns

Working from the 2025 list: reviews scoped on the old order miss arithmetic precision and upgradeability as named risks, and underweight flash loan amplification.
Treating the Top 10 as complete: randomness and gas griefing were removed, not solved, and the list says nothing about keys. Keep them in scope where they apply.
Fixing the multiplier, not the cause: blocking flash loans or adding a delay does not fix the rounding or logic flaw underneath, which a patient attacker can exploit with their own capital.
Trusting admin inputs: SC05 explicitly includes admin and cross-chain inputs. Parameter setters without range checks let a mistaken or coerced transaction set a collateral factor, fee or oracle address that drains users as surely as an exploit, so bound every setter in code and require a second reviewer for parameter changes.
Audit once, upgrade often: an audited version followed by unaudited upgrades is the SC10 failure in slow motion.
Ignoring the signer layer: the Bybit Hack 2025,, about 1.5 billion US dollars according to the FBI, used a compromised signing interface and genuine signatures, not a contract bug. OWASP's alternate Top 15 covers multisig compromise and phishing; read it alongside this list.

Practitioner checklist

Update review templates, audit scopes and finding taxonomies to the SC01:2026 to SC10:2026 IDs.
Write a role matrix and economic invariants before code review starts.
Run static analysis in CI for missing guards, unchecked calls, reentrancy shapes and tx.origin.
Fuzz invariants with large temporary balances to model flash loan amplification.
Document rounding direction for every share, interest and swap calculation, and test zero-supply cases.
Validate oracle freshness, deviation and source liquidity; define what happens when data is unavailable.
Initialise proxies atomically, lock implementations and diff storage layout on every upgrade.
Keep randomness, gas griefing, key custody and front-end integrity in scope despite their absence from the list.
Deploy on-chain monitoring for each applicable risk and rehearse the pause and cancel path.

OWASP Smart Contract Top 10 Guide: The 2026 Risks and How to Defend