Smart Contract Security: The Vulnerabilities That Have Cost Billions

Reentrancy is the vulnerability that enabled the $60M DAO hack in 2016 — the event that split Ethereum into ETH and ETC. It remains one of the most common exploit vectors today.

The attack works by having a malicious contract call back into the victim contract before the first execution completes. If the victim contract sends ETH before updating its balance, an attacker can repeatedly drain funds in a single transaction.

The fix is simple: always update state before making external calls, or use a reentrancy guard mutex. OpenZeppelin's ReentrancyGuard is the standard implementation. What is less simple is recognizing all the places where reentrancy is possible — cross-function reentrancy, cross-contract reentrancy, and read-only reentrancy are all real attack vectors that have been exploited.

Before Solidity 0.8, arithmetic operations silently wrapped around on overflow. A uint256 at its maximum value plus 1 would become zero. This allowed attackers to manipulate token balances, bypass supply caps, and drain funds.

The BEC token hack in 2018 used integer overflow to mint essentially unlimited tokens from nothing — destroying the token's value instantly.

Solidity 0.8+ has built-in overflow checks that revert on overflow, which eliminates the most common version of this bug. However, contracts using unchecked blocks, assembly, or older Solidity versions remain vulnerable. If you are auditing older code or using unchecked arithmetic for gas optimization, you need to verify overflow safety manually.

Access control vulnerabilities are the most boring security failures and among the most costly. The Ronin bridge hack ($625M) and the Nomad bridge hack ($190M) both had access control components.

The patterns vary: missing function visibility modifiers allowing public access to privileged functions, incorrect implementation of ownership transfer logic, failure to restrict initialization functions, and overly broad admin permissions that create single points of failure.

OpenZeppelin's Ownable and AccessControl contracts handle the common patterns correctly. The failure mode is almost always custom access control code that has subtle bugs. The rule is simple: do not write custom access control when battle-tested implementations exist.

DeFi protocols that rely on on-chain price data from DEX pools are vulnerable to flash loan attacks. An attacker can borrow enormous amounts of assets in a single transaction, manipulate a price oracle, exploit a protocol that trusts that price, and repay the flash loan — all in one atomic transaction.

This is how over $200M was drained from various lending protocols in 2021–2022 using Uniswap V2 spot prices as oracles.

The fix is using time-weighted average prices (TWAPs) rather than spot prices, using reputable external oracle networks like Chainlink, and ensuring that the economic cost of manipulation exceeds the potential profit from the exploit.

Internal review is necessary but not sufficient for contracts holding significant value. A proper security process includes unit tests covering edge cases (not just happy paths), static analysis tools like Slither and MythX, manual review by at least two engineers who did not write the code, and for significant contracts, an external audit by a specialist firm.

The external audit firms that matter: Trail of Bits, OpenZeppelin, Certik, Halborn, and Code4rena's competitive audit model. Budget $15,000–$50,000+ for a thorough audit depending on contract complexity.

Equally important: design your system so that a single contract exploit cannot drain everything. Timelocks on admin actions, value caps per transaction, and upgradeable contracts with multisig governance are all risk mitigation strategies that limit blast radius when something goes wrong — because in production, something eventually goes wrong.