Better Payment EUVD-2026-85025

Exploitable remotely and without authentication (PR:N/UI:N) against any site running Better Payment before 2.3.4 that sells a fixed-price item through the plugin's payment flow. The only prerequisite is a reachable payment/checkout submission where the attacker can control the amount parameter; exploitation is limited to reducing the charged amount (integrity/financial impact) and does not expose data or affect availability. Realistic risk is bounded to merchants actually using the plugin for paid transactions.

This is a business-logic / broken-access-control flaw (CWE-284) where the Better Payment plugin trusts a client-submitted payment amount instead of re-validating it server-side against the merchant's configured fixed price. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N = 5.3, MEDIUM) is internally consistent: network-reachable, low complexity, unauthenticated (PR:N), no user interaction, and integrity-only impact (I:L) with no confidentiality or availability effect - a fair characterization of a price-tampering bug that causes financial loss rather than data compromise. No EPSS score, no CISA KEV entry, and no public POC were provided, so there is no signal of active or automated exploitation; risk is real but bounded. The financial-fraud nature means motivated abuse is plausible wherever the plugin sells fixed-price items, but the impact is limited to underpayment/revenue loss per transaction rather than site takeover, keeping this firmly a medium-priority patch rather than an emergency. The 'Authentication Bypass' tag overstates the issue - nothing about authentication is bypassed; the flaw is missing server-side amount validation (authorization/business-logic).

An unauthenticated visitor loads a checkout/payment form for a fixed-price item, intercepts the submission (e.g., via browser dev tools or a proxy), and changes the amount field to an arbitrary lower value. Because the plugin builds the gateway charge from the submitted amount without re-checking it against the merchant's configured price, the reduced charge is processed, letting the buyer underpay. No public exploit code was referenced, but the manipulation is trivial and requires only ordinary request tampering.