DatingDapp

Summary

The vulnerability arises because the contract accepts Ether (with a minimum of 1 ETH) in the likeUser function but never updates the userBalances mapping with the received funds. As a result, the funds accumulate in the contract's overall balance rather than being assigned to individual users. Moreover, the withdrawFees function only allows withdrawal of Ether stored in the totalFees variable, which remains at zero due to the lack of updates in userBalances. Consequently, significant amounts of Ether can become permanently locked within the contract, posing a high-severity financial risk.

Vulnerability Details

In the current contract design, the likeUser function mandates that callers send a minimum of 1 ETH, which is then deposited into the contract's balance. However, the function fails to update the userBalances mapping with the received funds. As a result, even though the contract's overall balance increases, individual user balances remain at zero.

When a mutual like occurs, the matchRewards function is triggered. This function relies on the userBalances mapping to calculate the rewards and associated fees for the matched users. Since the mapping values are always zero, both the calculated rewards and fees are zero, preventing any Ether from being allocated to the deployed multisig wallet.

Furthermore, the only withdrawal mechanism provided by the contract is the withdrawFees function, which allows the owner to withdraw funds stored in the totalFees variable. However, because totalFees is only updated within the matchRewards function (and no fees are ever accumulated due to the unmodified userBalances), this function does not permit access to the Ether held in the contract's overall balance.

Consequently, significant amounts of Ether sent to the contract become permanently locked, as there is no proper mechanism to attribute and withdraw these funds. This design flaw presents a high-severity financial risk.

Impact

• Locked Funds: Significant amounts of Ether sent to the contract remain inaccessible because they are never properly attributed to user balances.

• Financial Loss: Users and stakeholders risk losing their funds permanently since there is no mechanism to withdraw the deposited Ether from the contract's balance.

• Degraded Trust: The inability to retrieve funds can lead to loss of confidence in the platform, potentially deterring further use and investment.

• Operational Risks: The contract's intended reward mechanisms fail, which can disrupt the application's overall functionality and user experience.

Tools Used

manual review

Recommendations

Update Fund Attribution:
Modify the likeUser function to properly update the userBalances mapping. For instance, add a statement like:

`userBalances[msg.sender] += msg.value;`