FEATURED POST
December 17, 2025
What is a Flashloan Attack? Overview by Sherlock
A flash loan attack uses temporary, uncollateralized capital to manipulate on-chain state and exploit protocol logic within a single transaction, revealing security flaws in how Web3 systems trust prices and state.
What is a Flashloan Attack? Overview by Sherlock
A flash loan attack is an exploit pattern where an attacker uses a flash loan to obtain large temporary capital inside one blockchain transaction, then uses that temporary capital to manipulate state or trigger faulty logic in another protocol, repays the loan before the transaction ends, and keeps the profit. The flash loan itself is not the vulnerable component. The vulnerable component is the target protocol that accepts a temporary state as truth during that same transaction.
A flash loan is an uncollateralized loan that must be repaid in the same transaction. If repayment does not occur, the entire transaction reverts and the chain state returns to its pre-transaction form. This relies on atomic transaction execution in the EVM. Atomic execution means the transaction either completes successfully and all state updates commit, or it fails and none of those state updates commit.
How flash loans change the attack surface
Flash loans remove the normal constraint that an attacker must already have capital to create market impact. With a flash loan, the attacker can borrow large size, execute a multi-step sequence across multiple contracts, and repay at the end of the transaction. This makes attacks feasible that depend on size, short-lived state distortion, or chained interactions.
In audits and incident reviews, the consistent root cause is not “flash loans exist.” The root cause is that the protocol performs a sensitive action based on state that can be changed inside the same transaction.
What a flash loan attack looks like at the transaction level
A flash loan attack is usually a single transaction that combines these elements:
The attacker borrows assets via a flash loan. The attacker uses borrowed assets to change on-chain state that the target protocol uses as an input. The attacker calls the target protocol while that input is distorted. The target protocol mints, redeems, borrows, liquidates, or transfers value based on the distorted input. The attacker then unwinds the temporary distortion, repays the flash loan plus fee, and retains remaining assets as profit.
This is possible because intermediate states inside the transaction are valid to the EVM even if they only exist for milliseconds and never appear as an end-of-block outcome.
The most common root cause: price or oracle misuse
The most common flash loan attack category is price manipulation. The target protocol reads a price from a source that can be moved inside the same transaction, then uses that price immediately to compute value transfer.
This occurs when a protocol uses a DEX spot price as an oracle, uses a shallow liquidity pool for pricing, uses a time-weighted average with a window that is too short for the risk model, or uses an oracle update cadence that can be forced or gamed during one transaction.
In practical terms, if a protocol can be made to believe an asset is worth more or less than it should be during the instant it performs a mint, borrow, redemption, or liquidation, value can be extracted.
Another common root cause: accounting logic that breaks under scale
A second common category is accounting and state sync failures that become profitable only when trade size is extreme. Examples include rounding behavior that creates a repeated advantage, balance tracking that diverges across mappings, shares-to-assets math that breaks under manipulated input values, or fee calculations that behave inconsistently at large notional sizes.
Flash loans do not create these bugs. Flash loans make it cheap to apply size until the math produces a meaningful payout.
Why “everything passed” during the exploit
Flash loan attacks often confuse teams because every check inside the target protocol may pass. That is because the protocol validated its own rules against inputs that were manipulated but still valid on-chain at that moment.
The attacker’s advantage comes from timing. The attacker chooses the exact moment when the protocol samples state, because the attacker controls the ordering inside the transaction. If the protocol reads state once and acts immediately, it gives the attacker a single sampling point to target.
This is also why flash loan attacks frequently involve composition across multiple protocols. The attacker uses one system to distort state, then uses another system that trusts that state.
Security principles that prevent flash-loan-enabled exploits
The primary security principle is: do not treat a single-transaction state snapshot as a reliable external truth for sensitive value transfer. If a protocol relies on external state such as prices, reserves, or exchange rates, it must assume an adversary can distort that state inside one transaction.
A related principle is: assume the attacker can obtain temporary size. Security assumptions that rely on “it costs too much to move the market” fail when uncollateralized size is available for one transaction.
Another principle is: separate observation from action when possible. Protocols that observe a value and immediately act on it in the same call path are easier to exploit than protocols that require time separation, multi-step confirmation, or constraints that limit how much a single transaction can change outcomes.
Finally: test at extreme sizes and adversarial ordering. Many systems are tested under normal usage patterns. Flash loan attacks use worst-case ordering and worst-case size.
Tip - Auditing principle: evaluate assumptions under atomic, adversarial execution.
A security review must trace full transaction paths, not isolated functions, and explicitly model how an attacker can combine flash loans, external calls, and state reads in a single execution. Audits that focus only on local invariants or expected user flows miss flash-loan-enabled failures, because the exploit lives in how correct components behave when composed under worst-case ordering and temporary capital.
In Summary
Flash loan attacks are a reminder that “valid on-chain” is not the same as “economically honest.” The EVM will happily execute temporary realities inside a transaction. Protocol security depends on designing around that fact.
At Sherlock, when we review protocols, we treat flash-loan-enabled manipulation as normal adversary behavior. If a protocol’s safety depends on capital limits, slow state changes, or polite transaction ordering, it is relying on assumptions that attackers do not follow.
If your protocol relies on on-chain prices, external state, or complex contract interactions, a single transaction can expose real risk. Contact Sherlock to review your contracts under adversarial execution assumptions before those weaknesses show up on-chain. Contact Sherlock for an Audit.
Flash Loan Attack FAQ
1. Are flash loans themselves unsafe or malicious?
No. Flash loans rely on atomic transaction execution and automatically revert if repayment fails. The risk comes from other protocols that accept manipulated state during the same transaction.
2. Why do flash loan attacks usually happen in one transaction?
Because Ethereum transactions are atomic. An attacker can borrow funds, change state, exploit logic, undo the state change, and repay the loan, all before the transaction commits.
3. Why are price-based exploits so common in flash loan attacks?
Many protocols read a price once and act on it immediately. If that price can be shifted inside the same transaction, the protocol may transfer value based on a distorted input.
4. Can a protocol be exploited by a flash loan without using an oracle?
Yes. Accounting errors, rounding behavior, share math, or balance tracking issues can all be abused when temporary capital allows the attacker to operate at extreme size.
5. Can flash loan attacks be fully prevented?
They cannot be eliminated at the platform level. Protocols reduce exposure by designing logic that does not trust single-transaction external state for sensitive value transfers and by assuming attackers can access temporary capital.
