After auditing dozens of DeFi protocols, certain vulnerability patterns appear with alarming regularity. These aren't exotic zero-days — they're well-documented issues that keep showing up because they're easy to introduce and hard to spot without focused review.
Here are the ones we see most often.
1. Price Oracle Manipulation
criticalHow often we see it: Nearly every DeFi protocol that uses external price data.
Flash loan
Attacker borrows a large amount in a single transaction
Price manipulation
Swaps to move the spot price in a DEX liquidity pool
Exploit
Interacts with the vulnerable protocol at the manipulated price
Unwind
Swaps back and repays the flash loan — profit extracted
🛑Never Use Spot Prices
Using getReserves() directly from a Uniswap pool as a price feed is one of the most common — and most dangerous — mistakes in DeFi. Use Chainlink, TWAP, or multi-source oracles instead.
What to do instead:
- Use Chainlink or other decentralized oracle networks
- Implement TWAP (Time-Weighted Average Price) calculations
- Add price deviation checks and circuit breakers
- Validate oracle response freshness (staleness checks)
2. Reentrancy in New Forms
criticalHow often we see it: About 30% of audits.
Most developers know about classic reentrancy. But it keeps appearing in subtler forms:
Reentrancy Variants
Classic
External call triggers fallback that re-enters the same function before state update.
Read-only
Calling a view function during execution that returns stale state. Common with Balancer/Curve integrations.
Cross-contract
Contract A calls Contract B, which calls back into Contract A through a different function sharing state.
Cross-chain
Bridge messages replayed or arriving while state is intermediate.
The fix: Always follow checks-effects-interactions. Use ReentrancyGuard on any function that makes external calls. For cross-contract scenarios, use reentrancy locks at the protocol level, not just the contract level.
3. Access Control Gaps
highHow often we see it: Almost every audit has at least one.
Common patterns:
- Missing access modifiers — Admin functions callable by anyone
- Single-owner risk — One compromised key takes down the protocol
- Incorrect role checks — Using
tx.origininstead ofmsg.sender - Upgradeable proxy risks — Implementation contracts not properly initialized
⚠️Real Example
We found a governance contract where executeProposal checked that a proposal had passed, but didn't verify the caller was authorized. Anyone could front-run the legitimate execution call.
4. Precision Loss in Financial Calculations
mediumHow often we see it: 40%+ of DeFi audits.
Solidity doesn't have floating-point numbers. Every division operation can lose precision, and these small errors compound:
- Reward distribution — Users staking small amounts receive zero rewards due to rounding
- Fee calculations — A 0.3% fee on a small transaction rounds to zero, allowing fee-free trades
- Share-based accounting — First depositor attacks where the attacker manipulates the share price
💡The Rule
Always multiply before dividing: a * c / b instead of a / b * c. Use 18 decimals minimum for financial values. Protect against first-depositor attacks with minimum deposits or virtual offsets.
5. Unprotected Initialization
criticalHow often we see it: 25% of audits, especially with upgradeable contracts.
When using proxy patterns (UUPS, Transparent Proxy), the implementation contract must be initialized separately from deployment.
Uninitialized implementation
Team deploys proxy + implementation but forgets to lock the implementation
Attacker calls initialize()
Takes ownership of the implementation contract directly
Self-destruct or upgrade
Attacker destroys or replaces the implementation, breaking the proxy
This was the root cause of the Wormhole hack ($326M) and several other major exploits.
6. Insufficient Validation on External Calls
highHow often we see it: 35% of audits.
- Not checking the return value of
transfer()(some tokens return false instead of reverting) - Not handling tokens with non-standard decimals
- Assuming all ERC-20 tokens behave identically (fee-on-transfer, rebasing tokens)
- Not validating callback data from flash loans
The fix: Use OpenZeppelin's SafeERC20 for all token transfers. Validate all return values. Test with fee-on-transfer and rebasing token mocks.
7. Governance Attacks
highHow often we see it: Every protocol with on-chain governance.
- Flash loan governance — Borrowing tokens to vote, then returning them
- Low quorum exploitation — Passing proposals when participation is low
- Timelock bypass — Finding ways around the delay mechanism
- Proposal griefing — Spamming proposals to exhaust community attention
The Pattern
ℹ️Why These Keep Happening
None of these are new. They're documented, well-understood vulnerabilities that teams keep introducing because of time pressure, composability complexity, copy-paste inheritance, and testing gaps that don't cover adversarial scenarios.
Vulnerability Frequency
~100%
Oracle Issues
40%+
Precision Loss
35%
External Call Bugs
30%
Reentrancy
Prevention
The most effective prevention is a combination of:
- AI-powered pre-screening — Catch the known patterns automatically before human review
- Expert manual audit — Deep-dive into protocol-specific logic and economic attacks
- Ongoing monitoring — Security doesn't end at deployment
Building a DeFi protocol? Get it audited before deployment. Our AI catches the common patterns so human auditors can focus on your protocol's unique risks.