DEV Community

juan23z
juan23z

Posted on

I ran my zero-false-positive scanner on Morpho Blue — all 3 findings were false positives

#security #solidity #ethereum #webdev

Public security note — Juan (juan23z). Solidity/DeFi security, calibrated to zero false positives across all of OpenZeppelin. Portfolio: https://juan23z.github.io · Open-source scanner: https://github.com/juan23z/openclaw-audit

TL;DR: I pointed my custom detector suite at Morpho Blue — one of the most respected, most-audited lending primitives in DeFi. It surfaced 3 candidates. After hand-verifying each against the source, all 3 are false positives. No real issues. Here's the interesting part: why they're safe is a small masterclass in secure Solidity design — and how I confirm they're safe is the whole point of a zero-FP process.

Most scanners would have reported these 3 as findings and handed you a scary PDF. I don't ship noise — I ship what I can prove.

The 3 candidates, verified by hand

1. "Cross-function reentrancy in liquidate()" → FALSE POSITIVE

My detector flagged an external call (token transfer + optional callback) in liquidate(). But Morpho Blue famously ships without a nonReentrant guard — on purpose. It's secure by strict Checks-Effects-Interactions:

  • All state mutations — position[id][borrower].borrowShares, market[id].totalBorrowShares/Assets, collateral, and the bad-debt realization — happen before any external interaction.
  • The token transfer and the opt-in onMorphoLiquidate callback come last, when the protocol's accounting is already fully consistent.

Re-entering during that callback buys an attacker nothing — the state they'd try to exploit is already settled. This is CEI done right, and it's why Morpho doesn't need a guard. Not a vulnerability.

2. "Cross-function reentrancy in _accrueInterest()" → FALSE POSITIVE

The flagged external call is IIrm(marketParams.irm).borrowRate(...). The key context a naive scanner misses: the IRM (interest-rate model) is fixed at market creation and is part of the immutable market parameters — it is not attacker-controlled. A reentrancy vector requires an attacker-controlled callee; this is a trusted, market-configured contract, and the accounting updates are safe regardless. Not a vulnerability.

3. "Fee-on-transfer token not supported" → FALSE POSITIVE (documented assumption)

True, but by design: Morpho Blue explicitly documents that it is not compatible with rebasing or fee-on-transfer tokens. Flagging a stated, intentional design assumption isn't a security finding — it's already in the spec. Not a vulnerability.

Why this matters if you're shipping a contract

A scanner that yells "HIGH: reentrancy!" at Morpho Blue — code audited by the best in the space — is exactly the false-positive spam that makes automated tooling useless. The value isn't in flagging; it's in verifying, and being honest when there's nothing to report.

That's what I do: custom detectors + line-by-line manual verification, calibrated to zero false positives across the entire OpenZeppelin library. When I hand you a report, every finding is real and proven — and if your code is clean, I'll tell you that (and show you why), instead of padding a document to look busy.

If you're pre-mainnet and want a review with no noise — just what's actually a risk — I'm around. A sample of the exact report format: https://juan23z.github.io/sample-audit-report.html

— Juan

Top comments (0)