Smart Contract Vulnerability Classes

Most Hacks Fall Into Known Patterns

Smart-contract exploits can seem mysterious, but the great majority fall into a handful of well-known vulnerability classes — recurring patterns of mistake that show up again and again across different projects. Learning these patterns is valuable not to make you an auditor, but to help you recognise the shapes of risk: why audits matter, why certain designs are riskier, and why 'it's on the blockchain' doesn't mean 'it's safe'. Because smart contracts are immutable (hard to change once deployed) and hold real money, a single instance of one of these bugs can be catastrophic and irreversible. Understanding the common classes demystifies how hundreds of millions have been lost and what defenders are guarding against.

A Few of the Big Ones

Some of the most important classes are easy to grasp in outline. Reentrancy: a contract calls out to another contract, which calls back in before the first has finished updating its records — letting an attacker withdraw repeatedly (the pattern behind the infamous DAO hack). Access control flaws: a sensitive function isn't properly restricted, so someone who shouldn't be able to (e.g. anyone) can call it — like leaving an admin door unlocked. Oracle manipulation: a contract relies on a price feed that an attacker can distort (often using a flash loan), tricking it into mispricing and letting the attacker drain value. Arithmetic errors: numbers overflowing or rounding wrongly, letting attackers mint or extract more than they should. Each is a specific, recognisable pattern, and each has caused major real-world losses.

• Most exploits fall into known, recurring vulnerability classes
• Reentrancy: re-entering a function before it finishes updating (the DAO hack)
• Access control: sensitive functions left unrestricted (an unlocked admin door)
• Oracle manipulation & arithmetic errors: distorting prices or numbers to extract value