Pieces Protocol

First Flight #32
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Submission Details
Severity: low
Valid

Overpayment Vulnerability in buyOrder Function Without Refund Mechanism

Title
The buyOrder function allows users to purchase ERC20 tokens from a sell order by sending Ether equivalent to the order's price. However, the function only checks if msg.value (the Ether sent) is less than the order price and reverts in that case. It does not handle scenarios where the buyer overpays (sends more Ether than required). The excess Ether remains in the contract, leading to a potential loss for the buyer since there is no mechanism to refund the overpayment.

Vulnerability Details

The buyOrder function found in line 270 validates the Ether sent by the buyer (msg.value) to ensure it is at least equal to the price of the order being purchased:
if (msg.value < order.price) {
revert TokenDivider__IncorrectEtherAmount();
}

However, the function does not validate against overpayment (i.e., msg.value > order.price). If the buyer sends excess Ether, the surplus is retained in the contract without any mechanism to refund the overpayment.

Impact

1. User Financial Loss:

  • If a buyer accidentally sends more Ether (msg.value > order.price), the excess Ether remains locked in the contract.

  • The buyer cannot reclaim the surplus without an explicit refund mechanism, leading to potential financial loss.

2. Locked Ether in the Contract:

  • Overpaid Ether accumulates in the contract. Unless an admin or withdrawal mechanism exists, these funds may become permanently inaccessible.

  • This creates inefficiencies and risks for the platform's financial management.

3. Erosion of User Trust:

  • Users expect fair handling of their funds. If overpayments are retained without clear communication or a refund, users may view the platform as untrustworthy or careless.

4. Reputational Risk for the Contract Owner:

  • Retaining overpaid funds can lead to negative publicity, especially if the issue affects many users. This might discourage potential users from engaging with the platform.

5. Compliance and Legal Risks:

  • In some jurisdictions, withholding overpaid funds without a refund mechanism might violate regulations or contractual obligations, exposing the contract owner to potential legal actions.

Tools Used

Manuel Review

Recommendations

To ensure proper handling of payments and prevent unintended overpayment, the following changes are recommended:

  1. Update the buyOrder Function to Validate Exact Payment: Replace the current conditional check for payment with a stricter validation. Modify to this:

    if(msg.value != order.price) {
    revert TokenDivider__IncorrectEtherAmount();
    }

  2. Implement Overpayment Refund Logic (Optional): If allowing overpayments is intentional (e.g., for user convenience), include logic to refund any excess Ether.
    if(msg.value > order.price) {
    uint256 overpayment = msg.value - order.price;
    (bool refundSuccess, ) = payable(msg.sender).call{value: overpayment}("");
    if (!refundSuccess) {
    revert TokenDivider__TransferFailed();
    }
    }

By enforcing strict validation or handling overpayments explicitly, the vulnerability is resolved, and the contract aligns with user expectations and best practices.

Updates

Lead Judging Commences

fishy Lead Judge 5 months ago
Submission Judgement Published
Validated
Assigned finding tags:

Token misshandling

The extra eth sent by the user in the buy order will be locked in the contract forever

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.