myCred < 3.2.5 – Unauthenticated Payment Bypass via Missing PayPal IPN Receiver Verification in buyCRED | CVE 2026-15150

Description

The plugin does not verify that the receiver of an incoming payment gateway notification matches the site's configured merchant account, allowing unauthenticated attackers to have arbitrary amounts of the site's in-site currency credited to an account by completing a payment for the expected amount to a gateway account they control rather than the site's.

Proof of Concept

Prerequisites (site config): buyCRED add-on enabled (default); PayPal Standard gateway enabled and configured with the site's own PayPal account email (Points > buyCRED > PayPal).

1. On the target, initiate a buyCRED PayPal purchase (e.g. buy 100 points). This creates
   a pending purchase record; note its public id (the "custom" value shown in the PayPal
   redirect form). Call it PENDING_ID and note the exact cost/currency.

2. From your own PayPal account, complete a genuine payment for that exact cost, but
   configure the payment so that:
       custom     = PENDING_ID
       notify_url = https://victim.example/?mycred_call=paypal-standard
   The money goes to YOUR PayPal account, not the site's.

3. PayPal sends a real IPN to the site's listener and returns VERIFIED on postback.
   Because the site never checks that the payment's receiver equals its own merchant
   account, it credits the points as if it had been paid. The IPN the site processes is
   equivalent to:

   POST https://victim.example/?mycred_call=paypal-standard
       custom=PENDING_ID
       txn_id=<your real PayPal transaction id>
       payment_status=Completed
       mc_gross=<exact cost>
       mc_currency=<currency>
       receiver_email=attacker@paypal.example   (your account, not the site's)
       business=attacker@paypal.example

Result: the buyer's myCred balance is credited although the payment went to the attacker.

4. Replay for unlimited credit: re-send the same notification, reusing the same transaction
   id, against a further pending purchase that differs in recipient or in amount. It is
   credited again. Only an exact duplicate of a previous notification is rejected, so one
   single real payment yields unlimited points.

5. Omitted-field variant: sending the notification with no payment-status field at all is
   also credited, because the status comparison is skipped when the field is absent.

Fixed in 3.2.5, where the receiver is compared against the configured merchant account and
the omitted-field variants are rejected. Note that 3.2.2 also rejected this, but 3.2.3 and
3.2.4 reverted that change.