Audit Firm Discovers Reentrancy-Class Bug Affecting Dozens of Forked Lending Protocols
A shared code template copied across dozens of forked DeFi lending protocols contains a reentrancy-class vulnerability, and teams are now racing to patch before it is exploited in the wild.
An audit firm has flagged a reentrancy-class vulnerability sitting inside a widely reused lending protocol codebase, and the disclosure has triggered an unusually public scramble as dozens of forked projects built on the same template race to ship patches before anyone works out how to weaponise it. The bug lives in a liquidation function that several major lending protocols popularised years ago and that has since been copied, with only cosmetic changes, into a long tail of smaller forks chasing the same yield-bearing collateral model.
Where the bug actually lives
The flaw sits in the interaction between a protocol's liquidation callback and its interest-accrual accounting. Under specific conditions, a borrower being liquidated can trigger a callback into an external contract before the protocol has finished updating its internal debt ledger, allowing a carefully constructed contract to re-enter the liquidation function and extract collateral valued against stale, pre-liquidation debt figures. It is a textbook reentrancy pattern in structure, but it is disguised by enough surrounding complexity — flash-loan-funded liquidations, multi-asset collateral pools, rebasing interest tokens — that it survived multiple rounds of audits across multiple forks without being caught.
That survival is the real story here. Reentrancy is the single most studied vulnerability class in smart-contract security, the subject of the original DAO hack in 2016 and of a decade of tooling built specifically to catch it. That a variant of it has apparently sat undetected across dozens of live protocols for an extended period says less about the sophistication of the bug and more about how audits scale, or fail to, when a single codebase gets forked hundreds of times.
The fork economy's structural weakness
DeFi's fork culture has always traded on the assumption that copying audited code inherits the safety of the original audit. That assumption breaks down in at least two ways, both visible in this incident. First, forks routinely modify the parts of a codebase that matter most for risk — collateral types, oracle sources, liquidation parameters — precisely the surface area an original audit was scoped against, without commissioning a fresh audit of those changes. Second, even forks that change nothing at all inherit whatever the original codebase got wrong, and a bug discovered in the template today was latent in every fork the day it launched, regardless of how many times that fork's own contracts were separately reviewed.
The result is a correlated risk that the market has generally underpriced. Depositors evaluating a forked lending protocol tend to look at its total value locked, its token incentives and perhaps a headline audit badge, rarely at whether the underlying template has had every downstream modification independently reviewed.
What protocols are doing about it
The disclosing firm coordinated a private notification window with the largest affected protocols before going public, giving teams time to pause liquidations or deploy patched contracts, and several of the largest forks confirmed emergency fixes were live within hours of disclosure. Smaller, less actively maintained forks are the greater concern: many are run by skeleton teams with limited capacity to respond quickly, and some have not updated their contracts in months. Users with open positions on any lending fork descended from the affected template should treat a pause in liquidations or an unscheduled contract migration as a signal to review their exposure rather than a routine maintenance notice, at least until the smaller end of the fork ecosystem confirms it has closed the gap.
