Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
A flash loan is not a vulnerability. It is atomic liquidity: assets are borrowed and repaid, with any fee, in one transaction or the transaction reverts. An attack labeled a flash-loan attack uses that temporary capital to exploit another weakness, such as a manipulable price, faulty share accounting, unsafe governance snapshot, or trusted callback.
ERC-3156 specifies a lender and receiver callback interface for single-asset flash loans. Other protocols use different interfaces. The loan removes the attacker's need to own capital for longer than one transaction, but it does not create profit on its own.
A vulnerable protocol often reads a value that an attacker can move temporarily, performs a consequential action at that value, and does not account for restoration later in the transaction. Examples include borrowing against an atomic spot price, minting shares from a transient balance, voting with uncheckpointed current balances, or liquidating against a market that the same transaction moved.
Flash-loan receiver code has a separate trust boundary. It must authenticate the lender and, when relevant, the initiator and callback data. Merely changing state inside a legitimate callback is not a defect; the issue is whether untrusted callback invocation or temporary state can violate an invariant.
Map every price, exchange rate, collateral value, voting balance, liquidity measure, and reserve value used in value-moving functions. Identify whether one transaction can change the input and consume the result. Trace nested callbacks and every external protocol invoked before repayment.
Test with capital up to the realistic flash-liquidity ceiling, but also search for minimal profitable amounts. Compose swaps, deposits, donations, borrows, liquidations, governance actions, and redemptions in different orders. Verify callback caller, initiator, asset, amount, fee, and encoded intent.
Use economic invariants: a round trip should not extract protocol value solely because an attacker temporarily changed a measured state. Include fees, slippage, liquidation bonuses, rounding, and multiple venues in profitability tests.
Use a price source designed for the protocol's manipulation horizon and liquidity. A time-weighted average can raise manipulation cost; the Uniswap v2 whitepaper explains its cumulative-price design and the freshness tradeoff of longer windows. A TWAP is not manipulation-proof, especially in thin markets or under multi-block control.
Validate oracle freshness, market depth, deviation bounds, and decimal conversions. Delay or checkpoint governance power when same-transaction acquisition is not intended. For ERC-3156 receivers, follow the standard's callback and initiator verification guidance and avoid standing approvals that untrusted initiation can consume.
Blocking known flash-loan providers is not a general defense. Equivalent atomic capital can come from other lenders, flash minting, large owned positions, or nested protocols. Fix the invariant that makes temporary capital profitable.
Repository analysis can identify callback surfaces, spot-price dependencies, and same-transaction state flows. It cannot prove economic exploitability, available liquidity, oracle-market depth, or all composable routes without deployment-specific state and simulation.
Should a protocol reject all flash-loan callbacks?
Only if it does not intentionally support them. The broader defense is to make critical calculations safe against atomic capital from any source.
Does an external price feed solve every flash-loan attack?
No. Accounting, governance, callback authentication, and stale or misconfigured feeds can remain vulnerable.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand missing and incorrect smart contract authorization checks, how to review privileged paths, and how to test role boundaries.
Review cross-chain message authentication, replay protection, finality, accounting, and operational trust boundaries.
Understand untrusted delegatecall targets, proxy upgrade boundaries, storage hazards, and practical review and test guidance.
Understand governance capture, flash-loan voting, unsafe proposal execution, and the review and testing needed for on-chain governance systems.
Understand unsafe price-feed consumption, stale and low-liquidity data, oracle trust assumptions, and practical review and mitigation techniques.