DeFi attack patterns: oracles, flash loans, proxies and signatures

The reentrancy guide at /domains/appsec/smart-contracts/security-invariants/ covers one class. The OWASP Smart Contract Top 10 (2026 edition), built from 2025 incidents and survey data, names several more. Three have entries of their own: price oracle manipulation, flash-loan-facilitated attacks, and proxy and upgradeability vulnerabilities. Signature replay has no entry; in practice it is an access-control failure (SC01:2026). The SWC registry that older material references is no longer maintained; use the Smart Contract Top 10 and current library docs instead.

A contract that reads the price from an AMM pool's reserves, or from a token balance, reads a number any trader can move. An attacker swaps into the pool to move the price, interacts with the victim at the manipulated price, and swaps back, all in one transaction. This lending contract values collateral from Uniswap v2 reserves, so a large swap inflates the collateral's apparent value and lets the attacker borrow far more than it is worth.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

interface IPair { function getReserves() external view returns (uint112, uint112, uint32); }

contract VulnerableLending {
    IPair public pair;

    // Vulnerable: price = reserve ratio, which a single swap (or a flash loan) moves.
    function collateralPrice() public view returns (uint256) {
        (uint112 r0, uint112 r1, ) = pair.getReserves();
        return (uint256(r1) * 1e18) / uint256(r0); // spot price, manipulable in one tx
    }
}

Read from an oracle an attacker cannot move within a transaction. A Chainlink data feed aggregates many sources; call latestRoundData and reject stale or non-positive answers, and on an L2 also check the sequencer uptime feed so you don't trade on a frozen price after an outage. Where a Chainlink feed is unavailable, a Uniswap v3 time-weighted average price (TWAP) over a long enough window raises the cost of manipulation, because the attacker must hold the price moved across many blocks. Bound how far a price may deviate between reads as a circuit breaker.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

interface AggregatorV3Interface {
    function latestRoundData()
        external view
        returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound);
}

contract SafeLending {
    AggregatorV3Interface public feed;
    uint256 public constant MAX_AGE = 3600; // reject prices older than one hour

    function collateralPrice() public view returns (uint256) {
        (, int256 answer, , uint256 updatedAt, ) = feed.latestRoundData();
        require(answer > 0, "bad price");                       // not zero or negative
        require(block.timestamp - updatedAt <= MAX_AGE, "stale price");
        return uint256(answer);
    }
}

A flash loan lends an uncollateralized amount that must be repaid within the same transaction (Aave v3's flashLoanSimple, or the ERC-3156 interface). It is not an exploit by itself; it removes the capital constraint that used to make manipulation uneconomic. With millions borrowed for one block, an attacker can move a spot oracle, win a governance vote that counts tokens held at that instant, or push a thinly-traded pool, then unwind and repay. The defenses are the ones in this guide: price from manipulation-resistant oracles, count governance votes from a past snapshot and add a timelock, and never trust a value that can change within the transaction.

Beanstalk lost about $181 million in April 2022: the attacker proposed malicious changes, waited out the one-day delay on emergency commits, then used a flash loan to take about 79% of the voting power within one transaction and called emergencyCommit to enact them. Voting power came from in-the-moment deposits, not a past snapshot. A Foundry fork test that borrows and manipulates within one transaction is the way to prove your contract resists this.

// A Foundry test sketch: prove the protected read resists single-tx manipulation.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

import {Test} from "forge-std/Test.sol";

contract OracleManipulationTest is Test {
    function test_spotPriceCanBeMovedInOneTx() public {
        // 1. snapshot price, 2. swap a large amount into the pool, 3. read price again:
        // the vulnerable spot read changes within the same transaction.
        // Assert the SafeLending read is unchanged (it uses the aggregator, not the pool).
    }
}

An upgradeable contract splits code (the implementation) from state (the proxy), and the proxy runs the implementation's code against the proxy's storage via delegatecall. If the implementation's storage layout disagrees with what the proxy already holds, a write lands on the wrong slot: a storage collision. This happens when a new version inserts or reorders a state variable, changes an inheritance order, or shares a slot with the proxy's own admin variables. OpenZeppelin Contracts 5.x avoids it with ERC-7201 namespaced storage, which puts a module's state at a hashed, collision-resistant slot rather than sequential slots 0, 1, 2.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

// ERC-7201 namespaced storage: state lives at a hashed slot, not slot 0,
// so adding or reordering variables in a later version cannot collide.
contract VaultStorage {
    /// @custom:storage-location erc7201:example.vault
    struct VaultData {
        uint256 totalAssets;
        mapping(address => uint256) shares;
    }

    // keccak256(abi.encode(uint256(keccak256("example.vault")) - 1)) & ~bytes32(uint256(0xff))
    bytes32 private constant SLOT = 0x... ; // set to the computed namespace slot

    function _vault() internal pure returns (VaultData storage v) {
        bytes32 slot = SLOT;
        assembly { v.slot := slot }
    }
}

The implementation contract is never meant to be used directly, only through the proxy, so its own storage should stay empty. If its initializer can still be called, an attacker can initialize the implementation, become its owner, and, in a UUPS setup, call an upgrade or (historically) a selfdestruct that bricks every proxy pointing at it. Call _disableInitializers() in the implementation's constructor so it can never be initialized on its own, use the initializer and reinitializer modifiers for actual setup, and guard the upgrade entry point with _authorizeUpgrade.

Parity's second multisig incident in November 2017 is the canonical case: a shared library contract was left uninitialized, a user took ownership of it and called its selfdestruct, and 513,774.16 ETH across 587 wallets became permanently frozen. The library had been built by copying wallet code that kept a callable self-destruct, and only wallets deployed after 20 July 2017 were affected.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

import {UUPSUpgradeable} from "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import {OwnableUpgradeable} from "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import {Initializable} from "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract Vault is Initializable, OwnableUpgradeable, UUPSUpgradeable {
    constructor() {
        _disableInitializers(); // the implementation itself can never be initialized
    }

    function initialize(address owner_) public initializer {
        __Ownable_init(owner_);
        __UUPSUpgradeable_init();
    }

    // Only the owner may upgrade; an unguarded _authorizeUpgrade lets anyone replace the logic.
    function _authorizeUpgrade(address) internal override onlyOwner {}
}

A contract that acts on a signed message must make each signature usable exactly once, for this contract, on this chain. This claim function hashes only the recipient and amount and recovers the signer with the low-level ecrecover. It has three replay problems: no nonce, so the same signature can be submitted again; no domain separator, so a signature meant for another contract or chain can be reused; and ecrecover accepts malleable (high-s) signatures, so a second valid signature exists for the same message.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

contract VulnerableClaim {
    function claim(address to, uint256 amount, bytes32 r, bytes32 s, uint8 v) external {
        // Vulnerable: no nonce, no domain separator, no deadline, raw ecrecover (malleable).
        bytes32 hash = keccak256(abi.encodePacked(to, amount));
        address signer = ecrecover(hash, v, r, s);
        require(signer == admin, "bad sig");
        _payout(to, amount); // replayable: submit the same signature again
    }
}

Use EIP-712 typed data: the domain separator includes the chain id and the verifying contract's address, so a signature is valid only for this contract on this chain, and it is recomputed if the chain forks. Add a per-signer nonce that you consume on use so a signature cannot be replayed, and a deadline so an old signature expires. Recover with OpenZeppelin's ECDSA.recover, which rejects high-s (malleable) signatures and the zero address. This pattern is the basis of EIP-2612 permit; for contract signers, verify with ERC-1271 instead of ecrecover. Signed webhooks need the same once-only and expiry checks: /domains/appsec/secure-features/verify-webhook-deliveries/.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
import {ECDSA} from "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";

contract SafeClaim is EIP712 {
    address public admin;
    mapping(address => uint256) public nonces; // one-time use per signer

    bytes32 private constant CLAIM_TYPEHASH =
        keccak256("Claim(address to,uint256 amount,uint256 nonce,uint256 deadline)");

    constructor() EIP712("SafeClaim", "1") {}

    function claim(address to, uint256 amount, uint256 deadline, bytes calldata sig) external {
        require(block.timestamp <= deadline, "expired");
        uint256 nonce = nonces[to]++;                       // consume the nonce
        bytes32 structHash = keccak256(abi.encode(CLAIM_TYPEHASH, to, amount, nonce, deadline));
        bytes32 digest = _hashTypedDataV4(structHash);      // binds chainId + this contract
        require(ECDSA.recover(digest, sig) == admin, "bad sig"); // low-s, non-zero signer
        _payout(to, amount);
    }
}

Prove the binding holds. Sign a claim with vm.sign, submit it once and expect success, then submit the identical signature again and expect a revert because the nonce is spent. Change the chain id with vm.chainId and confirm the same signature no longer verifies, and warp past the deadline with vm.warp and confirm it is rejected.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.37;

import {Test} from "forge-std/Test.sol";

contract SafeClaimTest is Test {
    function test_signatureCannotBeReplayed() public {
        // 1. (signer, key) = makeAddrAndKey("admin"); build the EIP-712 digest.
        // 2. (v, r, s) = vm.sign(key, digest); first claim succeeds.
        // 3. Replaying the same signature reverts (nonce spent).
        // 4. vm.chainId(other) then verify reverts (domain separator changed).
        // 5. vm.warp(deadline + 1) then verify reverts (expired).
    }
}

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Smart Contract Top 10 (2026)
2. OWASP SC03:2026 Price Oracle Manipulation
3. OWASP SC04:2026 Flash Loan-Facilitated Attacks
4. Chainlink Data Feeds API reference (latestRoundData and its timestamps)
5. Chainlink: L2 Sequencer Uptime Feeds
6. ERC-7201: Namespaced Storage Layout. Final (created 20 June 2023).
7. ERC-1967: Proxy Storage Slots. Final (created 24 April 2019).
8. OpenZeppelin Contracts 5.x: proxy and upgradeable utilities
9. EIP-712: Typed structured data hashing and signing. Final (created 12 September 2017).
10. Parity Technologies: a postmortem on the Parity multi-sig library self-destruct (archived copy). 15 November 2017.
11. US CFTC: charges against Avraham Eisenberg over the Mango Markets manipulation. Release 8647-23 (9 January 2023).
12. Halborn: explained, the Beanstalk hack (April 2022)
13. CertiK: Wormhole bridge exploit incident analysis
14. Foundry: cheatcodes reference (vm.sign, vm.warp, vm.chainId)

Reference information

Tags

Business logic and race conditionsSecurity testing

SDLC phase

DesignDevelopmentTesting

Role

Developers

Download this guide as Markdown

Continue exploring