5 Attacks Vectors Making DeFi Protocol Lose Billions (Simplified!)

Starter "Smart Contract Attack Vectors" Guide For Beginner Devs/Auditors

Since the launch of smart contracts 10 years ago, multiple hacks and attacks have resulted in over $50 billion being stolen from the space.

And if you've been in the space long enough, you must have seen one or two protocols hacked, compromised, or exploited. Regardless of the term used, the point is, funds were lost. Real funds from real people were lost from a single event by bad actors.

The real reason these exploits happened

At the deepest level, every exploit is a broken assumption.
Protocols assume something:
— “This function will only be called in this order.”
— “This price feed reflects reality.”
— “This contract behaves honestly.”
— “Users won’t do X.”
— “Governance won’t be abused.”
— “This invariant always holds.”
Attackers don’t exactly “hack the code”; they violate an assumption the code did not enforce and profit from it.

This is also true in Web2, it’s just far more expensive in Web3.

In this article, I will walk you through five common attack vectors that have drained billions from DeFi protocols. If you're a beginner dev or security researcher, this is for you.

5 main Web3 attack vectors (+1 bonus)

Most Web3 attack vectors fall into a small number of recurring patterns, and as smart contract engineers or auditors, it is our job to learn and understand them:

1. Logic and business logic flaws (the biggest category)

The most damaging Web3 exploits are usually not caused by low-level bugs, such as overflows or reentrancy. Instead, the code does exactly what it was written to do, but the economic or logical rules encoded in the system are wrong.

In these cases, nothing “breaks” at the programming level; the vulnerability exists because the protocol assumes certain behaviors or conditions that are not actually enforced.

Example 1: the Nomad Bridge exploit (2022, ~$190M)

A root hash was mistakenly initialized to 0x00, which effectively made any cross-chain message appear valid, the bridge didn’t malfunction, it followed its logic perfectly.

The real failure was the assumption that messages were always properly verified. Once this assumption collapsed, users were able to copy-paste the exploit and drain funds.

Example 2: the Beanstalk exploit (2022, ~$182M)

The attacker used a flash loan to temporarily acquire a majority of governance power, passed a malicious proposal, drained protocol funds, and repaid the loan all within a single transaction.

There was no Solidity “bug” involved, the protocol assumed that governance participants would act in good faith, but flash loans made that assumption invalid.

2. Oracle manipulation

Oracle manipulation occurs when a protocol places trust in external price data that can be influenced cheaply or temporarily.

Since smart contracts cannot independently verify real-world prices, they rely on oracles to provide that information, and when those oracles reflect markets with low liquidity or weak protections, attackers can distort prices long enough to extract value.

Example 1: Mango Markets (2022, ~$114M).

The attacker manipulated the price of the MNGO token on a low-liquidity market, artificially inflating its value. That inflated price was then used as collateral, allowing the attacker to borrow real assets from the protocol.

Once the transaction was completed, the manipulated price no longer mattered, the damage was already done.

The exploit worked because the oracle trusted a market that could be moved with relatively little capital. There were no strong time-weighted averages, circuit breakers, or sanity checks to detect abnormal price behavior. The protocol assumed that market prices reflected fair value, an assumption that attackers proved wrong.

Example 2: bZx (2020)

Followed a similar pattern to Mango Market.

Attackers used flash loans to manipulate oracle prices and exploit arbitrage opportunities, repeatedly draining value by taking advantage of short-lived price distortions.

3. Reentrancy (classic, but still relevant)

Reentrancy exploits occur when a contract makes an external call before updating its internal state.

This allows an attacker-controlled contract to re-enter the vulnerable function and repeat an action multiple times before the original execution finishes.

Example: The DAO exploit (2016, ~$60M)

The original smart contract hack that permanently shaped Ethereum security thinking.

The contract sent funds before updating balances, allowing attackers to recursively withdraw funds in a loop. Although modern Solidity patterns and tooling have reduced the prevalence of reentrancy, it has not disappeared. It still shows up in cross-contract interactions, ERC777 token hooks, and complex DeFi systems where execution flow becomes harder to reason about.

4. Access control and authorization failures

Access control failures happen when a system allows an entity to perform actions it should not be allowed to perform, or when ownership and permission boundaries are incorrectly defined.

Example 1: Ronin Bridge exploit (2022, ~$625M)

Attackers gained control of private keys belonging to validators and were able to authorize fraudulent withdrawals. The problem wasn’t a smart contract bug, it was that the system trusted a small validator set with a low approval threshold. Once those keys were compromised, the bridge had no remaining defenses.

Example 2: Poly Network exploit (2021, ~$610M), where improper access control in cross-chain message handling allowed an attacker to redirect assets across chains.

5. Unsafe external calls and trust in other contracts

Web3 systems are highly composable, meaning contracts frequently interact with other contracts. This creates risk when a protocol assumes that external contracts will behave in expected or “well-behaved” ways.

Example 1: Euler Finance exploit (2023, ~$197M)

The attack relied on subtle interactions between Euler’s internal accounting logic and the behavior of external tokens. By chaining these interactions together, attackers were able to exploit assumptions about how balances and liabilities were tracked.

Nothing here relied on a single broken line of code. The exploit came from complex interactions across contract boundaries, where assumptions no longer held once composability was pushed to its limits.

6. Upgradeability and initialization bugs (bonus)

Upgradeability introduces flexibility, but it also opens the door to an entirely new class of vulnerabilities. These exploits often involve uninitialized proxy contracts, exposed logic contracts, or unsafe upgrade paths.

Example 2: Audius exploit (2022, ~$18M)

Storage collisions and upgrade-related issues allowed attackers to manipulate the contract’s state and drain funds. The vulnerability did not come from day-to-day contract logic, but from the upgrade mechanism itself.

Upgradeability is powerful, but it shifts risk from immutable bugs to configuration and lifecycle errors. Upgradeability trades safety for flexibility, and that trade-off must be handled deliberately.

These 6 attack vectors are major patterns that cause breaches in DeFi protocols, although unique bugs or vulnerabilities are often found … these are a good start for beginners like me!

I intend to experiment with more technical content here on Substack (instead of pushing to Medium hahaha), fingers crossed to see how this goes.

Thanks for reading this letter. I tend to share stuff on security, web3 in general, client work, and my personal journey. Sub if you like that kinda stuff!