Root Cause: The liquidate() function transfers collateral to the liquidator before burning their DSC tokens. The liquidator's health factor is also checked only after receiving assets.
Impact: If the burn operation fails after collateral has been transferred, the liquidator receives collateral without paying. This allows attackers to extract collateral from underwater positions without providing any DSC, directly stealing from affected users.
Normal Behavior: During liquidation, the liquidator should atomically: burn DSC from their balance, reduce the user's debt, and receive collateral. The liquidator's health factor should remain valid throughout.
Issue: The liquidate() function redeems collateral to the liquidator before burning DSC. If the burn operation fails after collateral transfer, the liquidator receives free collateral. Additionally, the health factor check for the liquidator happens after they've already received assets.
Likelihood:HIGH
Reason 1 : Burn operation can fail if liquidator hasn't approved sufficient DSC
Reason 2 : Malicious liquidator can intentionally trigger failure after receiving collateral
Impact:
Impact 1 : Liquidator extracts collateral without paying DSC
Impact 2 : User's collateral is stolen without debt being reduced
An attacker with zero DSC tokens calls liquidate() on an underwater position. The _redeem_collateral() successfully transfers the victim's ETH to the attacker. When _burn_dsc() executes, it attempts to burn tokens the attacker doesn't have. If this fails silently (per H-03), the attacker keeps the collateral without payment.
Reorder the operations to follow the checks-effects-interactions pattern: burn DSC from the liquidator first, then transfer collateral. This ensures the liquidator must pay before receiving any assets.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.