Smart Contract Attack Vectors: Reentrancy, Read-Only Reentrancy & Flash Loan Manipulation

Read-Only Reentrancy: The Curve LP Token Price Oracle Exploit

Traditional reentrancy guards protect state-mutating functions (functions marked external or public that modify storage). However, read-only view functions are almost never protected by reentrancy locks because they do not modify state.

Read-Only Reentrancy occurs when a secondary protocol relies on the view function of a primary protocol as a price oracle while the primary protocol is in the middle of a state transition.

The classic Curve LP Read-Only Reentrancy Attack Vector:

1. Primary Pool (Curve / Balancer): A user calls remove_liquidity() on a Curve pool.
2. Intermediate State Inconsistency: The Curve contract burns the user's LP tokens and transfers the underlying tokens (e.g., ETH) back to the user before updating its internal virtual price state variable.
3. Fallback Trigger: During the ETH transfer, control is handed to the attacker's fallback hook.
4. Oracle Exploitation on Secondary Protocol: Inside the fallback hook, the pool has less ETH, but its LP token supply has not updated yet. As a result, calling Curve's get_virtual_price() returns an artificially depressed or inflated price.
5. Borrowing / Liquidating: The attacker calls a secondary lending protocol that uses Curve's get_virtual_price() as a pricing oracle, borrowing massive assets against undervalued collateral or triggering false liquidations before the Curve transaction finishes and restores accurate pricing.

Defense against Read-Only Reentrancy: Secondary protocols must never query raw spot view functions from external pools without verifying that the target pool is not currently locked in an active reentrancy state. Protocols can call reentrancy lock inspection functions or enforce reentrancy guards across view methods using EIP-1153 transient storage.

Flash Loan Price Oracle Manipulation: Why Spot Prices Are Fatal in DeFi

A Flash Loan allows anyone to borrow millions of dollars of cryptocurrency without collateral, provided the borrowed principal plus a tiny fee (e.g., 0.05% on Aave) is repaid within the exact same atomic transaction block.

If a DeFi protocol queries the spot reserves of an Automated Market Maker (such as UniswapV2Pair.getReserves()) to determine asset prices, an attacker can manipulate the oracle risk-free using flash loans.

The Flash Loan Oracle Manipulation Attack Flow:

1. Borrow: Attacker borrows $50,000,000 USDC via flash loan.
2. Manipulate Spot AMM: Attacker dumps all $50M USDC into a USDC/WETH liquidity pool on Uniswap, causing the spot price of WETH in that pool to skyrocket artificially.
3. Exploit Vulnerable Protocol: Attacker deposits 100 WETH as collateral into a vulnerable lending protocol. The protocol calculates collateral value by querying the manipulated Uniswap spot reserve, calculating that the 100 WETH is worth $10,000,000insteadof$300,000.
4. Over-Borrow: Attacker borrows $8,000,000 in real stablecoins from the lending vault against the fake collateral valuation.
5. Rebalance & Repay: Attacker swaps back on Uniswap (recovering most of the dumped USDC) and repays the $50M flash loan, pocketing millions in stolen vault funds.

Why Spot Oracles Fail: Spot prices reflect only the current marginal ratio of tokens in an AMM pool at a single discrete instant. They represent the cost of the last trade, not the global fair market value.

The Solution: Decentralized Oracles (Chainlink) & TWAP: Protocols must use Time-Weighted Average Price (TWAP) oracles (such as Uniswap v3 TWAP over a 30-minute window) or decentralized oracle networks (such as Chainlink Decentralized Oracle Networks with multi-source medianization and outlier rejection), which cannot be manipulated in a single atomic flash-loan transaction.

Case Study: Euler Finance $197M Donation Logic Exploit

In March 2023, Euler Finance suffered a $197 million exploit—one of the largest in DeFi history. The vulnerability was not in external oracle manipulation or standard reentrancy, but in a subtle logic flaw in their donateToReserves() function.

The Root Cause Analysis:

1. Collateral and Debt Tracking: Euler used internal liquidity tokens (eTokens) to represent deposits and debt tokens (dTokens) to represent borrowed liabilities.
2. The Health Check Invariant: Whenever a user borrowed funds or withdrew collateral, Euler's smart contract executed a health check verifying that $\text{CollateralValue}\ge \text{DebtValue}\times \text{CollateralRatio}$.
3. The Missing Health Check: In an upgrade (EIP-14), Euler added a donateToReserves() function allowing users to donate collateral to the protocol reserve. However, the developers omitted the health check inside donateToReserves().
4. The Exploit Execution:
5. Attacker leveraged flash loans to deposit $20Mandmint$200M in leveraged collateral and debt.
6. Attacker called donateToReserves() to donate their collateral eTokens to the reserve.
7. Because the donation lacked a health check, the attacker's account was left in an underwater state (enormous debt with zero collateral).
8. Liquidating such a severely underwater position triggered a liquidation bonus calculation algorithm that minted massive eTokens to the liquidator (also controlled by the attacker), converting bad debt into withdrawable funds and draining $197M.

The Takeaway: Invariant testing must enforce that every state-mutating function validates global account solvency, regardless of how harmless the function appears.

Arithmetic Precision Loss, Rounding Exploits & First-Depositor ERC-4626 Attacks

In the EVM, integer division truncates toward zero: $5\mathrm{/}2=2$. If arithmetic calculations in token vaults or AMMs perform division before multiplication, severe precision loss occurs:

$$\text{Incorrect: }(A\mathrm{/}B)\times C\mathrm{\ne }\text{Correct: }(A\times C)\mathrm{/}B$$

The First-Depositor / Inflation Attack on ERC-4626 Tokenized Vaults: In standard ERC-4626 vaults, shares minted for a deposit are calculated as:

$$\text{Shares}=\frac{\text{DepositAmount}\times \text{TotalShares}}{\text{TotalAssets}}$$

If an attacker is the very first depositor in an empty vault:

1. Attacker deposits $1$ wei of asset and receives $1$ wei of share ($1:1$ initial ratio).
2. Attacker front-runs a legitimate user's deposit of $10,000$ USDC by directly transferring $10,000$ USDC directly to the vault contract address (without calling deposit()).
3. Now: $\text{TotalAssets}=10,001$ USDC, $\text{TotalShares}=1$.
4. When the victim deposits $10,000$ USDC:

$$\text{VictimShares}=\frac{10,000\times {10}^6\times 1}{10,001\times {10}^6}=0(\text{Truncated to 0!})$$

1. The victim receives $0$ shares, but their $10,000$ USDC remains in the vault. The attacker then redeems their $1$ single share, withdrawing both their original deposit and the victim's $10,000$ USDC!

Defenses against Inflation Attacks:

• Virtual Shares & Assets: Modern implementations (such as OpenZeppelin ERC4626) add virtual offset shares (e.g., $+{10}^3$ virtual shares) to the denominator, preventing share price manipulation.
• Dead Shares Burning: The vault permanently mints and burns the first $1,000$ shares to the zero address on initialization.

## Access Control Failures: Unprotected Initializers, Signature Replay & tx.origin

Beyond complex algorithmic flaws, access control oversights continue to cause multi-million dollar hacks:

1. Unprotected Initializer Functions in Proxies:

Upgradeable implementation contracts use initialize() functions instead of constructors. If the implementation contract itself is left uninitialized on-chain, an attacker can call initialize() directly, become the contract owner, and call self-destruct or malicious delegatecalls (as seen in the Nomad and Wormhole bridge incidents). Mitigation: Use OpenZeppelin's _disableInitializers() in implementation constructors.

1. Signature Replay Attacks:

If a contract verifies an off-chain ECDSA signature for meta-transactions without enforcing a chainId, contract address, and unique per-user nonce, the attacker can reuse the same signed payload across different chains or repeatedly on the same contract. Mitigation: Enforce EIP-712 structured typed data signatures with domain separators.

1. Authentication via tx.origin instead of msg.sender:

Using require(tx.origin == owner) allows phishing attacks: if the owner interacts with a malicious contract, that malicious contract can call the protected vault and pass the authentication check because tx.origin remains the owner's EOA. Mitigation: Always use msg.sender for authorization.

Frequently asked questions

Why does the Checks-Effects-Interactions (CEI) pattern prevent reentrancy?

By updating internal balances and state variables before making external calls or token transfers, any recursive reentrant call will see the decremented balance and immediately fail the initial checks.

How do virtual shares prevent ERC-4626 vault inflation attacks?

Virtual shares add a fixed non-zero offset to the share calculation denominator, making it mathematically impossible for an attacker to inflate the share price so high that subsequent user deposits round down to zero.

Why should smart contracts avoid using spot prices from Uniswap pools?

Spot prices reflect only the current token balance in a single pool and can be manipulated instantaneously within a single transaction using uncollateralized flash loans.

Related reading

• invariant testing smart contracts against reentrancy attacks — Learn how to detect reentrancy and oracle vulnerabilities automatically using fuzzing tools.

## Sources

• Security Considerations: Reentrancy — Solidity docs
• Echidna: property-based fuzzer for Ethereum smart contracts — Trail of Bits

No contributor to this article holds a professional cryptography or security credential. Every technical claim above is sourced to primary protocol documentation rather than to personal authority — follow the sources and verify anything you intend to act on.

Not financial advice. Crypto assets are volatile and can lose value. This article describes how protocols work, not what you should buy.