Arbitrary address by an Attacker can cause loss of Funds!

Description:

The withdrawAllFailedCredits function contains a logic error where it reads the credited amount for an arbitrary address supplied by the caller (failedTransferCredits[_receiver]) but clears and pays out from/to the caller (failedTransferCredits[msg.sender] and payable(msg.sender)). Because the _receiver parameter is user-controlled, a caller can specify any victim address and the function will:

• Read the victim’s stored credit amount into amount from failedTransferCredits[_receiver].

• Clear the caller’s own mapping entry failedTransferCredits[msg.sender] (leaving the victim’s mapping untouched).

• Transfer amount to the caller (msg.sender) regardless of ownership of that credit.

Crucially, the function never resets failedTransferCredits[_receiver] (the victim’s mapping entry) after transfer, so the same victim balance can be read and paid out repeatedly. This allows an attacker to repeatedly call the function with a victim’s address and continuously receive the victim’s recorded credit amount until the contract’s ETH balance is depleted/drained.

The mismatch between the mapping key used for reading (_receiver) and the mapping key used for clearing (msg.sender), combined with sending funds to the caller rather than the credited address, creates a direct theft vector: funds attributed to arbitrary accounts in the failedTransferCredits mapping can be siphoned by any caller. The only practical limit to exploitation is the contract’s available ETH balance.

This behaviour constitutes a direct, repeatable loss of funds for the contract and its users and therefore represents a high-risk, critical vulnerability.

Risk : Loss of Funds

Likelihood:

• This will occur at a high likelihood as the address parameter is user controlled

• Attacker can always steal funds

Impact:

• Loss of precious Funds

• Owners funds depleted / Whole Contracts ETH which came from Fees will be drained

  
  

Recommended Mitigation: