Closed code423n4 closed 3 years ago
Recommended mitigation makes sense. Disagreeing with severity as there is no real issue that can arise from this, so makes it a 0 in my mind.
Marking this as non-critical as it does not have an impact on the users / protocol usage.
closed and marked duplicate per judge.
Handle
pauliax
Vulnerability details
Impact
Function claimEscrow does not validate that the receipt exists thus it is possible to pass an arbitrary id of non-existent receipt. Basically, receiptId is assigned from currentLiquidationId which then increments. If you call claimEscrow with non yet existing receiptId, this function will retrieve a receipt initialized with default values, that is, escrowClaimed is set to false, receipt.releaseTime and escrowedAmount are 0. This function will execute successfully but the attacker does not get any direct value from it. I can't see any serious attack vector for now, even though escrowClaimed is set to true, it is later overridden in function submitLiquidation but anyway I think it would make sense not to accept invalid receipt ids.
Recommended Mitigation Steps
Check that receiptId < currentLiquidationId.