A sophisticated exploit against Resupply's crvUSD-wstUSR pair created $10M of reUSD bad debt.
The vulnerability was unique to that specific pair. No other pairs are affected, and all Resupply markets continue to operate as usual.
The protocol guardian has set the debt limit to 0 on the affected pair and paused insurance pool withdrawals, with a formal governance vote required to unpause.
The exploit flow involved inflation of the CurveLend collateral shares, but differed from a classical "inflation attack" as it was carefully designed to nullify a borrower solvency check.
The section of code containing the issue was within scope for multiple security audits and independent researchers who were hired to review the codebase. None reported the issue.
Users are encouraged to visit the Resupply governance forums for updates on next steps.
Resupply accepts ERC-4626 vault shares (CurveLend / FraxLend) as CDP collateral.
Oracles price vault shares via convertToAssets(), treating crvUSD and frxUSD as 1:1 with reUSD.
Resupply makes use of an Insurance Pool (IP) designed to facilitate liquidations and backstop bad debt across all pairs.
2025-06-26 00:18:47 UTC — crvUSD-wstUSR pair deployed with a $10M debt limit; underlying CurveLend vault held 0 deposits.
2025-06-26 01:53:59 UTC — Attack contract deployed and exploit executed (~1 h 35 m later).
2025-06-26 02:53:23 UTC - Protocol guardian pauses affected pair.
Because the Curvelend vault had no deposits, it made it possible for the attacker to dramatically manipulate the share price, making 1 wei of shares worth 2e18 crvUSD by:
donating 2,000e18 crvUSD to the vault's controller (which holds vault funds)
depositing 2e18 crvUSD to mint 1 wei of vault shares
While share price manipulation is a critical step in this attack, it alone is not a problem for the Resupply oracle, as the true value of the shares is tracked correctly.
Unlike a traditional "inflation attack", the attack relied on triggering the following edge case in the smart contract logic:
The oracle uses a hardcoded 1e18 shares parameter to correctly price the shares:
_price = IERC4626(_vault).convertToAssets(1e18); // returns 2e36
The pair then calculates the reUSD exchangeRate using the following evm math, which rounds to 0.
exchangeRate = 1e36 / oracle.getPrices(collateral); // 1e36 / 2e36 floors to 0
While an exchange rate of 0 in the previous step may appear harmless, it is relied upon in the following solvency check during each borrow operation:
function _isSolvent(address _borrower, uint256 _exchangeRate) internal view returns (bool) {
...
uint256 _ltv = ((_borrowerAmount * _exchangeRate * LTV_PRECISION) / EXCHANGE_PRECISION) / _collateralAmount;
return _ltv <= _maxLTV; // _ltv = 0 ➔ always solvent
}
The multiplication by 0 breaks solvency check by causing the user's LTV to resolve to 0, thus causing _isSolvent() to return true regardless of the attacker's actual loan to value ratio.
This sequence of logic allowed the attacker to borrow up to the pair's full 10M reUSD debt limit.
The protocol guardian has paused the affected pair, setting its borrow limit to 0.
The Resupply treasury has used treasury funds to repay 643,051 reUSD debt
A new interest rate calculator was added to the pair to set its interest rate to 0%, preventing interest from accumulating on the bad debt.
The withdrawal timer window has been set to zero, temporarily blocking insurance pool assets from exiting until a governance proposal is passed.
A permissionless share burner contract has been deployed, funded, and used to trustlessly ensure all Resupply pairs are safe from a similar attack.
A formal governance proposal will facilitate the disposition of insurance pool assets, and to unblock the funds.
Stolen funds remain on-chain. The situation is being monitored and necessary steps are being taken.
Patch ResupplyPairCore.sol and ResupplyPairDeployer.sol to permanently defend against this form of attack.