#04 SC04:2026 High ↑ from #7

Flash Loan-Facilitated Attacks

Flash loan-facilitated attacks describe exploits where an attacker uses uncollateralized, same-transaction borrowing to amplify underlying vulnerabilities (logic, pricing, or arithmetic) into large drains by executing complex multi-step sequences in a single transaction.

Official OWASP description, from scs.owasp.org (CC BY-NC-SA 4.0).

Why this rank in 2026

Promoted from #7 to #4 and renamed to "Flash Loan-Facilitated" - OWASP's framing change emphasizes that flash loans are a *facilitator*, not a root cause. The category jumped because 2025 saw a sharp rise in chained exploits using flash loans to amplify SC02, SC03, and SC07 bugs.

Why OWASP renamed this category in 2026

The 2026 list is the first time OWASP explicitly calls flash loans a facilitator, not a root cause. That is the right framing. A flash loan never extracts value on its own - it amplifies a bug that already exists somewhere else (typically SC02 business logic, SC03 oracle, or SC07 rounding). Treating it as a category teaches developers to assume flash loans exist and design protocols to be safe under that assumption.

How 2025 exploits played out

Bunni (Sep 2025) lost $8.4M when a rounding error in withdrawal was amplified through 44 chained tiny withdrawals after flash-borrowing 3M USDT. The flash loan was not the bug - the rounding was - but the loan turned a 0.05% leak into an $8.4M drain.
zkLend (Feb 2025) lost $9.5M when integer-division rounding in mint() inflated the lending accumulator. Flash loans were the "force multiplier" that scaled the exploit to nine figures.

Why it jumped from #7 to #4

Two-thirds of 2025's biggest exploits used flash loans as a primitive. The composability premium has grown: every new protocol assumes flash loans exist, and attackers assume every protocol assumes that. The category is no longer a niche concern; it is a default attack tool.

How AI auditors handle this category

The hard part of flash loan exploits is the composition reasoning: which sequence of operations across which contracts in a single transaction extracts value? AI auditors can detect that a function uses a flash loan, but constructing the specific chain that breaks a particular protocol is still a multi-step economic argument. Stateful fuzzers like Echidna and Foundry's invariant testing close some of the gap, but only when the right invariants are written by a human first.

See /attacks/flash-loan-attacks for SCH's deep dive on the standard patterns.

2025 incidents tied to this category

Pulled live from the SCH hack database, ordered by amount lost. Click any incident for the full post-mortem.

View the full SCH hack dashboard →

Vulnerable vs secure code

✗ Vulnerable solidity

// Vulnerable: share-price calculated from spot reserves; flash loan can mint shares cheaply
function mint(uint256 assets) external returns (uint256 shares) {
    uint256 totalAssets = token.balanceOf(address(this));
    shares = totalShares == 0
        ? assets
        : assets * totalShares / totalAssets;       // spot-price share math
    totalShares += shares;
    require(token.transferFrom(msg.sender, address(this), assets));
}

✓ Secure solidity

// Secure: cooldown + cap + TWAP-derived share price
function mint(uint256 assets) external nonReentrant returns (uint256 shares) {
    require(block.number > lastMintBlock[msg.sender], "same-block mint blocked");
    require(assets <= maxMintPerTx, "exceeds cap");
    uint256 pricePerShare = _twapSharePrice(1800);  // 30-min TWAP
    shares = assets * 1e18 / pricePerShare;
    lastMintBlock[msg.sender] = block.number;
    totalShares += shares;
    require(token.transferFrom(msg.sender, address(this), assets));
}

AI vs human auditor on this category

Each bar is a detection rate: out of 100 known flash loan attacks bugs, how many that auditor type finds. Higher means more reliable. The gap below is the percentage-point difference - the work senior humans still do that AI does not.

AI auditor (frontier LLM)

42%

Human auditor (senior)

80%

% of SC04 bugs caught - higher is better.

Human advantage on SC04

+38 percentage points

Senior auditors catch 38 more flash loan attacks bugs per 100 than frontier AI today. That gap is the skill the SCH course teaches.

AI tools recognize flash-loan callees and can flag obvious composability risks, but reasoning about *which* combination of operations creates value extraction inside a single block is a multi-step economic argument that current frontier models still struggle to construct.

Methodology: EVMbench, Cecuro purpose-built agent benchmarks, and senior-auditor self-reported catch rates. SCH editorial, not OWASP-authored.

Prevention checklist

Assume flash loans exist; design every protocol with this assumption.
Rate-limit sensitive operations per-block, per-epoch, or with dynamic fees.
Cap exposure per interaction via slippage and position caps.
Simulate flash-loan scenarios in testing and stateful fuzzing.
Combine flash-loan-aware design with strong oracles and business-logic invariants.
Address root causes (SC02, SC03, SC07) - flash loans only multiply existing bugs.

Detection tools

Industry-standard tools that detect this category. Tool mappings are SCH editorial - OWASP's per-category pages do not list specific tools.

Echidna

fuzz

flash-loan invariant fuzz harnesses

Foundry

fuzz

invariant tests with flash-loan handlers

Medusa

fuzz

parallel flash-loan scenario coverage

Slither

static

basic flash-loan source detection only

Deep dive: related SCH attack pages

FAQ

What is OWASP SC04 Flash Loan-Facilitated Attacks?

SC04 covers exploits where an attacker uses uncollateralized, same-transaction borrowing to amplify underlying vulnerabilities (business logic, oracle, arithmetic) into large drains by executing complex multi-step sequences in a single transaction. It is #4 in the OWASP Smart Contract Top 10 2026, promoted from #7 in 2025.

Why is a flash loan not the root cause of an exploit?

A flash loan never extracts value on its own. It amplifies an existing bug elsewhere - SC02 business logic, SC03 oracle, or SC07 arithmetic rounding. OWASP renamed the category to "Flash Loan-Facilitated" in 2026 specifically to make this framing explicit. Treating flash loans as a facilitator teaches developers to assume flash loans exist and design protocols to be safe under that assumption.

Why did flash loan attacks jump from #7 to #4 in OWASP 2026?

Two-thirds of 2025 biggest exploits used flash loans as a primitive. Bunni lost $8.4M when a rounding error was amplified by a flash-borrowed 3M USDT across 44 chained tiny withdrawals. zkLend lost $9.5M when integer-division rounding was scaled through flash loans. The composability premium has grown so much that flash loans are now a default attack tool rather than a niche concern.

How do you defend a DeFi protocol against flash loan attacks?

Assume flash loans exist when designing any DeFi protocol. Rate-limit sensitive operations per-block or per-epoch, cap exposure per interaction via slippage and position caps, simulate flash-loan scenarios in stateful fuzzing (Echidna, Foundry invariants), combine flash-loan-aware design with strong oracles and business-logic invariants, and most importantly fix the root causes (SC02, SC03, SC07) that flash loans amplify.

Can AI auditors detect flash loan vulnerabilities?

AI auditors recognize flash-loan callees and can flag obvious composability risks (catch rate around 42%), but reasoning about which combination of operations creates value extraction inside a single block is a multi-step economic argument that current frontier models still struggle to construct. Senior human auditors detect around 80% of cases.

Sources & methodology

Every claim on this page traces back to a primary, citable source. Open the originals if you want to verify the numbers or read the underlying methodology.

Official

OWASP Foundation

SC04 category page

Canonical description, root causes, and references for Flash Loan Attacks in the 2026 list.

Project

OWASP Foundation

Smart Contract Top 10 2026

Project landing page covering scope, governance, and the full 10-category ranking.

Methodology

OWASP Foundation

Data sources & ranking method

How OWASP scored each category from 2024-2025 incident data, audit reports, and contributor surveys.

Dataset

CredShields

Web3HackHub incident database

Continuously updated public dataset of on-chain exploits used to cross-check loss figures.

Quoted OWASP descriptions are used under CC BY-NC-SA 4.0. SCH editorial content (analysis, code, prevention prose, FAQ, AI-vs-human rates) is © Smart Contract Hacking.

Continue through OWASP 2026

← Back to the OWASP 2026 hub

Master the techniques that make this category exploitable

The SCH Smart Contract Hacking Course teaches the exploit primitives, audit techniques, and tool workflows for flash loan-facilitated attacks and every other OWASP 2026 category.

Explore the course Estimate an audit