Exploitable reentrancy in contracts that already passed an audit
What we learned running exploit validation against a set of previously audited lending and vault contracts.
By Opsec Research
An audit is a snapshot. Protocols keep changing after the report is published: new markets are listed, integrations are added and helper contracts are upgraded. We wanted to know how often those changes reintroduce a class of bug the original review had cleared.
We ran the smart contract agent against a set of lending and vault deployments whose most recent audit reported no open reentrancy issues, and kept only findings that produced a working exploit on forked mainnet state.
Where the paths came from
Most confirmed paths did not live in the audited contract itself. They appeared where audited code called into something added later — a reward distributor, a token with transfer hooks or a periphery router that updated balances after an external call.
Read-only reentrancy was the most common variant: a view function returned a stale share price while a withdrawal was mid-flight, and a second protocol trusted that price.
What the repairs looked like
The generated fixes were small. In most cases they moved a state update ahead of the external call or added a guard that also covered the view functions other protocols read from. Each repair was checked against the original exploit and the project’s existing tests before it was proposed.