Exploit Case Studies: The Recurring Patterns

The biggest crypto hacks look different on the surface but rhyme underneath — a handful of patterns cause most of them, and you can learn to spot them.

Crypto & Tokenization · Lesson 42 · 11 min read

You’ve now met the individual weaknesses — reentrancy (lesson 37), oracle manipulation (38), bridge honeypots (34), liquidation cascades (30), human error (17). This capstone steps back and asks the more useful question: what do the real, headline-making hacks have in common? Because while every exploit has unique details, they rhyme — a small number of recurring patterns underlie the vast majority of losses. Learn the patterns and you can smell danger in a protocol you’ve never seen before, which is worth more than memorizing any single hack. Hold the question: if the specific bugs are all different, what deeper shapes keep showing up across the biggest disasters?

Pattern 1: unexpected composition

The first recurring shape: pieces that are each fine alone break when combined in a way no one anticipated. Reentrancy (lesson 37) is exactly this — a normal external call plus a normal withdraw, composed in the wrong order, drains everything. Flash-loan attacks (lesson 38) are the master example: flash loans are fine, AMMs are fine, oracles are fine — but composed in one atomic transaction, they let an attacker borrow millions, bend a price, and rob a protocol that each piece would never have allowed alone. DeFi’s superpower is composability — protocols snapping together like Lego — and it’s also its curse: every new combination is an untested interaction, and attackers hunt for the one nobody reasoned through. The lesson: a system is only as safe as the interactions it wasn’t designed for.

Patterns 2 & 3: trusting a manipulable input, and concentrated value

Pattern 2 — trusting an input an attacker controls. Over and over, a protocol relies on some value as “truth” that turns out to be cheap to fake: a spot price an attacker can move (oracle manipulation, lesson 38), a signature or message that can be forged (many bridge hacks, lesson 34). The protocol’s logic is fine; it just trusted the wrong thing. The defense is always the same question from lesson 38: how expensive is it to lie to this system? Pattern 3 — concentrated value. Attackers are economically rational (lesson 17): they go where the money is piled up. A bridge locking hundreds of millions (lesson 34), a lending pool, a treasury — concentration is a magnet, and the bigger the pile behind one contract, the more brilliant and well-funded the attackers probing it. These aren’t separate from pattern 1; real hacks usually stack them — an unexpected composition that manipulates a trusted input to drain a concentrated pile.

A generic flash-loan oracle hack, decoded into patterns:
• Unexpected composition (1): flash loan + AMM + lending protocol combined atomically.
• Manipulable input (2): the lending protocol trusts a spot price the flash loan can move.
• Concentrated value (3): the lending pool holds a big pile worth stealing.
• All three at once — which is why these hacks recur: the patterns compound.

Pattern 4: the human, and the attacker mindset

The last pattern is the oldest: the human and the process. A shocking share of catastrophic losses aren’t clever code exploits at all — they’re stolen keys, phished signers, insider mistakes, or sloppy deployment (the human-target reality from lesson 17, now at institutional scale). No amount of formal verification (lesson 41) saves you if an attacker simply gets the keys (which is why key management, lesson 40, matters so much). Put the patterns together and you get the module’s enduring mindset: assume you are a target, and think like the attacker. Before trusting a protocol, ask: What unexpected combination could break this? What input does it trust that could be faked? How much value is concentrated here, and who guards the keys? This adversarial habit — the same “disprove, don’t approve” instinct behind good auditing — is the real graduation from this module. You won’t memorize every hack, but you can learn to see the shapes that keep causing them. (Neutral and educational — the goal is to help you evaluate safety, not to enable attacks.)

Pattern-spotting a new protocol before trusting it:
1. Composition: does it snap together many other protocols in novel ways? Each combo is an untested interaction.
2. Trusted inputs: what does it treat as “truth” — a price, a signature, an off-chain feed — and how expensive is that to fake?
3. Concentration: how much value sits behind one contract, making it a honeypot?
4. Humans: who holds the keys, can they upgrade it, and how are they protected? Run this checklist and you’re thinking like an attacker — which is exactly how you spot the danger first.