Why AI Code Review Misses DeFi Exploits (And What Actually Catches Them)

@jetpippo ran a DeFi contract through Claude for a quick audit. It came back clean. It wasn't. The bug that got missed — an oracle read that a flash loan could manipulate in a single transaction — is one of the most common exploit patterns in DeFi history. It's also exactly the kind of bug a general-purpose LLM is structurally bad at catching.

This isn't a "Claude is dumb" post. It's a "you're using the wrong tool for this job" post. Here's why AI code review misses this class of bug, and what to run instead.

Why LLMs miss DeFi-specific exploits

General-purpose AI code review is trained to catch general-purpose code problems: unhandled exceptions, off-by-one errors, SQL injection, obvious reentrancy where a state change happens after an external call. It's genuinely good at that stuff.

DeFi exploits don't usually look like bugs. They look like correct code that violates an economic invariant the model has no way to know about. Three specific gaps:

• No protocol-level context. An LLM reading a getPrice() function sees a function that returns a number. It doesn't know that number comes from a single Uniswap pool's spot reserves, which means it doesn't know that number is manipulable within one block by anyone with enough capital (which, with a flash loan, is anyone). The vulnerability isn't in the syntax — it's in the relationship between that function and every other DeFi protocol using single-source spot pricing that's been drained since 2020.
• No cross-transaction reasoning. Flash loan attacks work because borrow, manipulate, exploit, and repay all happen atomically in one transaction. LLMs reviewing code read it roughly top-to-bottom, function-by-function. They're not simulating "what if 50,000 ETH shows up, does something, and leaves, all before this function returns."
• Training data skew. LLMs have seen millions of examples of generic web app vulnerabilities and comparatively few examples of DeFi-specific exploit postmortems, because those postmortems are scattered across Twitter threads, incident reports, and security firm blogs — not neatly labeled training corpora the way "SQL injection" patterns are.

The result: Claude, GPT, whatever you're using — they'll catch the reentrancy guard you forgot, the unchecked transfer() return value, the missing access modifier. They will almost never flag "this price feed can be manipulated" unless you specifically prompt for it, and if you knew to prompt for it, you probably didn't need the audit.

What actually catches this: pattern-matching against real exploits

This is where Decurity's Semgrep smart contract rules come in. It's not an AI tool — it's static analysis, and that's the point. Semgrep matches code structure against defined patterns, and Decurity built their ruleset by reverse-engineering actual DeFi exploit postmortems into detectable code shapes.

Instead of "does this code look reasonable," the rules ask "does this code match the structural signature of a hack that already happened." Categories the ruleset covers:

• Single-source price reads used directly in collateral or liquidation math (the oracle manipulation pattern)
• Functions callable mid-flash-loan that change protocol state without checks
• Reentrancy patterns beyond the basic checks-effects-interactions violation — including cross-function and cross-contract reentrancy
• Unsafe delegatecall usage in upgradeable proxies
• Access control gaps on functions that move funds or change critical parameters
• Unchecked low-level call return values

700+ GitHub stars and it's still underused, which tracks — most teams either pay for a full manual audit (correct, but slow and expensive) or run an AI review and call it done (fast, but blind to exactly the bugs that matter most in this domain).

Worked example: catching an oracle manipulation bug

Here's the walkthrough. Say you've got a lending vault contract with a price function like this:

function getCollateralValue(address token, uint256 amount) public view returns (uint256) {
    (uint112 reserve0, uint112 reserve1,) = pair.getReserves();
    uint256 price = (uint256(reserve1) * 1e18) / uint256(reserve0);
    return (amount * price) / 1e18;
}

Step 1 — AI review. You paste this into Claude with "audit this for security issues." You'll typically get back notes on visibility, maybe a comment about using SafeMath if you're on an old Solidity version, possibly a note that view functions can still be gas-expensive. Clean bill of health on the actual vulnerability, because nothing about this code looks wrong in isolation — it's reading reserves and doing division. Syntactically correct, semantically a live grenade.

Step 2 — run Decurity's rules. Install Semgrep and pull the ruleset:

pip install semgrep
git clone https://github.com/Decurity/semgrep-smart-contracts

Run it against your contracts directory:

semgrep --config semgrep-smart-contracts/rules/ ./contracts/

The oracle-manipulation rule category matches on the structural pattern here: a getReserves() call feeding directly into a price calculation with no time-weighting, no multi-block sampling, and no fallback oracle. You'll get a flagged finding pointing at that exact function, with a description tying it to the same pattern used in a string of real incidents — Harvest Finance, Cheese Bank, and more recently smaller forks that copy-pasted vulnerable vault logic without understanding why it was vulnerable.

Step 3 — fix and re-scan. Swap the spot read for a TWAP oracle or a Chainlink feed, re-run Semgrep, confirm the finding clears. Takes minutes, not a multi-week audit cycle.

AI review vs static analysis vs manual audit

| | AI code review (Claude/GPT) | Semgrep + Decurity rules | Manual audit firm | |---|---|---|---| | Speed | Seconds | Seconds to minutes | Weeks | | Cost | Free–$20/mo | Free, open source | $10k–$100k+ | | Catches generic bugs | Yes | Partial (pattern-specific) | Yes | | Catches known DeFi exploit patterns | No, unless specifically prompted | Yes, by design | Yes | | Catches novel/business-logic exploits | No | No | Sometimes | | Best used as | First pass, code quality | Pre-audit gate, CI check | Pre-mainnet, pre-TVL-scale |

The honest take: none of these replace the others. Run AI review for speed on day-to-day PRs. Run Semgrep with Decurity's rules on every commit as a CI gate — it's free and catches known-pattern disasters before they ship. Pay for a manual audit before you put real TVL at risk, because novel exploits that don't match any known pattern still need a human who thinks like an attacker.

Common mistakes

• Treating "Claude said it's fine" as an audit. It's a first pass at code quality, not a security audit. Use it to catch typos and obvious bugs, not to sign off on mainnet deployment.
• Running Semgrep once and never again. Wire it into CI so it runs on every PR. New DeFi exploit patterns get published constantly — pull the ruleset updates and re-scan periodically, not just at launch.
• Ignoring findings because "it's just a warning." Static analysis findings on oracle reads and access control are exactly the ones worth stopping to investigate, even when they don't crash the build.
• Skipping manual audits because static analysis passed clean. A clean Semgrep run means "no known exploit pattern matched." It does not mean "no exploit exists." Business-logic bugs specific to your protocol won't match a generic ruleset.

FAQ

Can AI tools ever catch DeFi-specific exploits like oracle manipulation?

Sometimes, if you explicitly prompt for it — "check for oracle manipulation risk" gets meaningfully better results than "audit this contract." But relying on the user to already know what to ask defeats the purpose of an audit. Treat AI review as a quality pass, not a security guarantee.

Is Semgrep alone enough to secure a DeFi protocol before mainnet?

No. Static analysis catches known patterns; it can't reason about your protocol's specific economic logic or catch novel exploits. Use it as a fast, free pre-filter before a paid manual audit, not a replacement for one.

What's the difference between Decurity's rules and generic Semgrep Solidity rulesets?

Generic Solidity rulesets mostly check code-quality and common-bug patterns (unchecked calls, visibility issues). Decurity's rules are specifically derived from postmortems of real DeFi exploits — oracle manipulation, flash loan attack surfaces, proxy upgrade risks — so they're tuned to catch the failure modes that have actually drained protocols, not just generic smart contract hygiene issues.

---

→ Ask the index what to build your defi security stack

→ Free credits for these tools

Written by McKlaud AI. Want to know which AI tools actually fit your business? Get a free AI audit.