Best Payments Plugin EUVD-2026-101527

Exploitation requires the attacker-supplied input to be stored by the Best Payments Plugin for WP (wp-payment-form, versions up to and including 4.6.27) and then rendered, and per UI:R it requires a victim - typically a logged-in administrator - to subsequently view the stored content in the WordPress dashboard for the script to fire. The CVSS vector's PR:N implies the malicious data can be injected without authentication (consistent with a public-facing payment/submission form), but if the vulnerable sink is instead an authenticated plugin area this would require at least a low-privilege account; this should be confirmed against the Patchstack advisory. Limiting factors: dependence on admin interaction (UI:R), the site must have this specific plugin installed and the affected feature in use, and impact is scoped to browser-context actions rather than direct server compromise.

This is a moderate-severity Stored XSS (CWE-79) in the WPManageNinja 'Best Payments Plugin for WP' (wp-payment-form), rated CVSS 7.1 by the Patchstack reporter. The 7.1 is elevated largely by the Scope change (S:C) and triple partial impact (C:L/I:L/A:L) typical of Patchstack's stored-XSS scoring, rather than by any evidence of mass exploitation. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no indication of active or imminent exploitation - this reads as a routine, responsibly-disclosed plugin XSS rather than an urgent priority. The CVSS vector claims AV:N/PR:N/UI:R, i.e. remote and unauthenticated, which is plausible for a payment-form plugin where unauthenticated visitors submit form data that is later rendered in the wp-admin dashboard; however, many WordPress stored-XSS issues actually require a low-privilege authenticated account (contributor/author), so the PR:N claim should be verified against the Patchstack advisory. One signal conflict worth noting: the vector asserts A:L (availability impact), which is unusual for reflected/stored XSS - availability impact from XSS is generally negligible, suggesting the input score is somewhat inflated. Overall real-world risk is moderate-to-low: meaningful where the plugin is installed and an admin can be induced to view attacker-controlled data, but not a drop-everything issue absent any exploitation telemetry.

An attacker submits a payment form (or a contributor-level account saves plugin-managed content) containing a malicious JavaScript payload, which the plugin stores without proper neutralization. When a site administrator later views the submission or related entry in the WordPress dashboard, the script executes in their authenticated browser session, enabling session/cookie theft or admin-context actions. No public exploit code was identified at time of analysis.