The bidBeastMarketPlace:: withdrawAllFailedCredits function is intended to allow users to withdraw their funds when refund transfers fail. However, the function takes an arbitrary _receiver parameter to fetch the withdrawal amount from the bidBeastMarketPlace:: mapping(address => uint256) public failedTransferCredits; mapping but then resets the mapping for msg.sender instead of _receiver.
This creates a mismatch between whose balance is reduced and who receives the funds.
As a result, any user can pass another user’s address (with failed credits) as _receiver and drain their funds.
Likelihood:
Critical fund loss: Attackers can withdraw other users’ failed refunds, resulting in theft of protocol/user funds.
Protocol insolvency: Malicious actors can continuously exploit this function until all stored failed credits are drained.
Breaks trust in the auction system: Honest bidders will lose their refunds, making the marketplace unusable.
Impact:
Critical fund loss: Attackers can withdraw other users’ failed refunds, resulting in theft of protocol/user funds.
Protocol insolvency: Malicious actors can continuously exploit this function until all stored failed credits are drained.
Breaks trust in the auction system: Honest bidders will lose their refunds, making the marketplace unusable.
Assume the following state in the mapping:
Bidder1 calls:
so msg.sender is bidder1 with less bid(1 ether)
and _reciever is bidder2 with higher bid (2 ether),
Execution flow:
Transfers 2 ETH to Bidder1
End state:
failedTransferCredits[Bidder2] still 2 ETH
But Bidder1 already stole the 2 ETH
This can be repeated indefinitely by calling again with Bidder2’s address and drain the protocol funds
Update the bidBeastMarketPlace:: withdrawAllFailedCredits function to ensure the caller can only withdraw their own failed credits. Remove the _receiver parameter and enforce msg.sender as the only source of withdrawal:
Use msg.sender only and remove _reciever input
withdrawAllFailedCredits allows any user to withdraw another account’s failed transfer credits due to improper use of msg.sender instead of _receiver for balance reset and transfer.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.