Malicious lenders can perpetually deny borrowers of repaying their loan leading to higher debt
Summary
Users can repay their debt during an auction, but a malicious lender can front-run the repayment transaction by bidding on the loan through another address they control. This causes the user's transaction to fail, as the loan enters the "auctioned" status. The malicious lender can set the new loan to a "called" state in the same transaction, continuously increasing the debt. Since they pay themselves the debt and only need to cover the protocol fee (which may be minimal or zero), they can perpetually front-run any repayment attempt.
Root Cause
I dont think there is a certain code which is the root cause for this. The inability for the borrower to repay his debt is that the initial loan is auction and there is a new loan with new loanId and the fact that after bidding for a loan, new lender can set the loan in to called status in the same transaction.
Malicious lender calls a loan and loan gets into an auction.
Borrower tries to repay by providing loanId = X.
Lender frontrun borrower transaction and bid for the loan from another address owned by him.
Loan with id = X is now in auctioned state.
New loan has new loanId = X + n (where n is the number of new loans which were created between this moment and when already auctioned transaction was created).
Borrower transaction revert as loan with id X cannot be repayed.
The same scenario can be done perpetually by the lender.
Another scenario involves the new lender repeatedly increasing the loan in an atomic transaction. They can bid on the loan, set it to a "called" state, and then bid on the new loan, continuing this cycle. The extent of this exploit depends on the amount of protocol fees they are willing to pay and the value of the collateral.
Impact
Innability for borrowers to repay loan, or repay with artificially increased debt amount.
PoC
No response
Mitigation
One possible solution is when loan has been auction to not create a new loan and update the current one. This way the user's transaction wont revert but execute in slightly higher debt. This will require a slippage parameter provided by the user for the amount of debt he is ready to pay.
Another approach would be to set a constant minimum duration of such auctioned loans (which is the opposite of the current design), so that the lender have time to react.
Add checks to stop bidding for a loan and setting in to called state in the same transaction.
Stable Midnight Canary
High
Malicious lenders can perpetually deny borrowers of repaying their loan leading to higher debt
Summary
Users can repay their debt during an auction, but a malicious lender can front-run the repayment transaction by bidding on the loan through another address they control. This causes the user's transaction to fail, as the loan enters the "auctioned" status. The malicious lender can set the new loan to a "called" state in the same transaction, continuously increasing the debt. Since they pay themselves the debt and only need to cover the protocol fee (which may be minimal or zero), they can perpetually front-run any repayment attempt.
Root Cause
I dont think there is a certain code which is the root cause for this. The inability for the borrower to repay his debt is that the initial loan is auction and there is a new loan with new loanId and the fact that after bidding for a loan, new lender can set the loan in to called status in the same transaction.
auction(): https://github.com/sherlock-audit/2024-09-predict-fun/blob/41e70f9eed3f00dd29aba4038544150f5b35dccb/predict-dot-loan/contracts/PredictDotLoan.sol#L561Internal pre-conditions
Loan is called by lender.
External pre-conditions
N/A
Attack Path
Perpetually increasing scenario:
Another scenario involves the new lender repeatedly increasing the loan in an atomic transaction. They can bid on the loan, set it to a "called" state, and then bid on the new loan, continuing this cycle. The extent of this exploit depends on the amount of protocol fees they are willing to pay and the value of the collateral.
Impact
Innability for borrowers to repay loan, or repay with artificially increased debt amount.
PoC
No response
Mitigation
One possible solution is when loan has been auction to not create a new loan and update the current one. This way the user's transaction wont revert but execute in slightly higher debt. This will require a slippage parameter provided by the user for the amount of debt he is ready to pay.
Another approach would be to set a constant minimum duration of such auctioned loans (which is the opposite of the current design), so that the lender have time to react. Add checks to stop bidding for a loan and setting in to called state in the same transaction.