Chapter 6

Smart Contract Vulnerabilities

Smart contracts run in a hostile environment. Any public function can be called by anyone, in any order, and often from another contract with unexpected side effects. Security bugs are usually logic errors, not broken cryptography.

The OWASP-style catalog for Solidity groups recurring failure modes. Knowing these patterns helps users evaluate protocol risk and helps builders design defensively from the first line of code.

Most expensive hacks trace back to a small set of well-documented mistakes.

Common Solidity vulnerability classes

Vulnerability	What goes wrong	Mitigation
Reentrancy	External call before state update	Checks-effects-interactions; reentrancy guards
Access control	Privileged function callable by anyone	Role-based modifiers; multisig admin
Integer issues	Overflow or precision loss in math	Solidity 0.8+; fixed-point libraries
Oracle manipulation	Price feed gamed for profit	TWAP, multiple sources, circuit breakers

Audits hunt for these patterns, but no report guarantees safety. Users should still ask whether a protocol has upgrade keys, external calls, and oracle dependencies.

Reentrancy made history with early DAO exploits, but access control failures remain common in admin functions left unprotected after a refactor. Always ask who can pause, upgrade, or withdraw protocol reserves.

Composability multiplies risk. Your contract may be sound in isolation yet unsafe when called through a flash loan, a manipulated oracle, or a malicious token with a custom transfer hook.