Smart Contract Security Vocabulary: Reentrancy, Flash Loans, and Front-Running Explained
Master smart contract security vocabulary: reentrancy attacks, flash loan exploits, front-running, access control vulnerabilities, and professional English for audit reports.
Smart contract security is one of the most consequential areas of software engineering — a single vulnerability in a DeFi protocol can result in millions of dollars lost with no recourse. Every blockchain developer, auditor, and security researcher working in the Web3 space needs precise English vocabulary to discuss, document, and remediate vulnerabilities. This guide covers the most important attack vectors, audit terminology, and security practices with definitions and real-world usage.
Core Smart Contract Vulnerabilities
Reentrancy
Reentrancy is one of the most famous smart contract vulnerabilities. It occurs when a contract makes an external call to an untrusted contract before updating its own state, allowing the malicious contract to re-enter the original function recursively before the state is updated.
How it works:
- Contract A calls Contract B (e.g., to transfer ETH)
- Contract B’s fallback function calls back into Contract A before the transfer transaction completes
- Contract A’s balance hasn’t been updated yet — so the attacker can drain funds repeatedly
“The DAO hack of 2016, which resulted in the loss of 3.6 million ETH, was caused by a reentrancy vulnerability in the withdrawal function.”
Prevention vocabulary:
- Checks-Effects-Interactions pattern (CEI) — a defensive coding pattern: check conditions first, update state, then call external contracts
- Reentrancy guard / nonReentrant modifier — a mutex that prevents a function from being called while it is already executing
- Pull-over-push payment pattern — instead of pushing funds to users, allow them to pull (withdraw) externally
Flash Loan Attacks
A flash loan is an uncollateralised loan that must be borrowed and repaid within a single transaction. Legitimate use cases include arbitrage and collateral swaps. However, flash loans can be weaponised to manipulate oracle prices or governance votes within a single block.
Flash loan attack vocabulary:
- Flash loan — a loan of arbitrary size that must be returned within the same transaction; no collateral required
- Price oracle — a data feed that tells a smart contract the current market price of an asset
- Oracle manipulation — using a flash loan to move the price in a DEX’s spot pool, feeding a false price to an oracle that other contracts rely on
- AMM (Automated Market Maker) — a smart contract that enables token swaps using a pricing formula (e.g., Uniswap’s x*y=k)
- Sandwich attack — a variant where an attacker front-runs and back-runs a victim’s trade using a flash loan
“The attacker used a $50M USDC flash loan to artificially inflate the price of the collateral token in the Uniswap V2 pool, triggering an undercollateralised borrow in the lending protocol before the loan was repaid within the same block.”
Prevention:
- Use TWAPs (Time-Weighted Average Prices) instead of spot prices as oracles — harder to manipulate in a single block
- Use Chainlink or other off-chain data feeds for price-sensitive logic
Front-Running and MEV
Front-running in blockchain occurs when a miner, validator, or MEV bot sees a pending transaction in the mempool and inserts their own transaction ahead of it to profit.
MEV (Maximal Extractable Value) — the total value a miner or validator can extract by reordering, inserting, or censoring transactions within a block.
MEV vocabulary:
- Mempool — the pool of pending, unconfirmed transactions visible to validators
- Gas price bidding — paying higher gas to get a transaction included and ordered first
- Sandwich attack — front-running a swap by buying before it (increasing the price) and selling after (capturing the slippage)
- Arbitrage bot — a bot that captures price discrepancies between DEXs automatically
- Slippage — the difference between expected and actual trade price
- Commit-reveal scheme — a two-step pattern that hides a transaction’s intent until the commit phase is final
“The Flashbots protocol was developed as a response to the MEV crisis — it allows searchers to submit transaction bundles privately to validators, reducing harmful front-running in the public mempool.”
Access Control Vulnerabilities
Smart contracts must carefully control who can call which functions. Access control failures are among the most common vulnerabilities.
Types:
Ownership vulnerabilities — functions intended for admin use left accessible to anyone
tx.origin vs msg.sender — using tx.origin instead of msg.sender for authentication allows phishing attacks via malicious intermediary contracts
Privilege escalation — a function that allows an attacker to grant themselves elevated permissions
Missing access modifiers — an initialize() function callable by anyone, not only the deployer
“The exploit was possible because the
setOwner()function lacked anonlyOwnermodifier — any address could claim ownership of the contract and drain the treasury.”
Prevention vocabulary:
- onlyOwner / onlyRole — Solidity modifiers restricting access to specific addresses
- OpenZeppelin AccessControl — a standard library implementing role-based access control
- Timelock — a delay between a privileged action being queued and executed
- Multisig — requiring multiple authorised signers to approve sensitive operations
Integer Overflow and Underflow
Prior to Solidity 0.8, arithmetic operations did not revert on overflow. An uint that exceeded its maximum value would wrap around to zero.
“Solidity 0.8.0 introduced automatic overflow/underflow protection. Pre-0.8 contracts required SafeMath library — ensure any legacy contract you audit uses SafeMath or has been migrated.”
Terms:
- Overflow — a value exceeding the maximum of its data type, wrapping around
- Underflow — a value going below zero in an unsigned type, wrapping to the maximum
- SafeMath — a library providing safe arithmetic operations (now built into Solidity 0.8+)
Logic Errors and Business Logic Bugs
Not all exploits are exotic. Many are simple logic errors in contract design.
Examples:
- Incorrect order of operations in reward calculations
- Rounding errors favouring attackers (repeatedly rounding down in the attacker’s favour)
- State machine bugs — invalid state transitions allowed
“The exploit leveraged a rounding error in the yield calculation: for each 1 wei deposited, the attacker received 1 full token of yield due to truncation. By repeating this 10 million times in a loop, they drained $4M.”
Audit Vocabulary
Severity Levels
| Level | Definition |
|---|---|
| Critical | Immediate fund loss or protocol takeover possible; must be fixed before deployment |
| High | Significant fund loss or functionality compromise possible |
| Medium | Partial fund loss or degraded functionality possible under non-trivial conditions |
| Low | Minor issue or best-practice deviation; low probability of exploitation |
| Informational | Not a vulnerability; observation or code quality note |
Audit Report Phrases
“We identified a critical reentrancy vulnerability in the
withdraw()function at line 142. An attacker can recursively callwithdraw()before the balance mapping is updated, draining the contract’s ETH balance.”
“The
transferOwnership()function lacks a two-step ownership transfer pattern. We recommend implementing apendingOwnervariable and require the new owner to accept by callingacceptOwnership(), preventing accidental transfer to an incorrect address.”
“The contract correctly implements the Checks-Effects-Interactions pattern throughout. No reentrancy vulnerabilities were identified.”
Common Audit Phrases
| Phrase | Usage |
|---|---|
| Attack vector | The path an attacker uses to exploit a vulnerability |
| Exploit | A technique or script that weaponises a vulnerability |
| Proof of concept (PoC) | A working test demonstrating that an exploit is possible |
| Mitigation | A change that reduces or eliminates a vulnerability |
| Remediation | The process of fixing a vulnerability |
| Test coverage | The percentage of code covered by automated tests |
| Invariant | A condition that must always be true in a contract (used in formal verification) |
| Formal verification | Mathematical proof that a contract behaves as specified under all conditions |
Practice
Deepen your smart contract and blockchain security vocabulary with the Blockchain exercise set and explore all resources on the Blockchain Developer learning path.