WP User Frontend EUVD-2026-96225

Requires an authenticated account with subscriber-level privileges or higher on a site running WP User Frontend ≤4.3.12 with its payment/transaction submission flow in use. The specific prerequisite is that the attacker control the 'wpuf_payment_method' parameter and append a valid gateway keyword (e.g. 'bank') to the HTML payload so that sanitize_text_field() returns only the keyword for routing while the full raw malicious value is persisted. Execution is deferred and depends on a victim - typically an administrator - later viewing the page (the admin transactions list) where the stored value is rendered unescaped. Limiting factors: the account requirement rules out fully unauthenticated attack, and impact is only realized when a privileged user opens the affected page.

This is a moderate-severity, authenticated Stored XSS (CWE-79) in the WP User Frontend plugin, confirmed and reported by Wordfence with a CVSS 3.1 base of 6.4 (AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N). The signals are consistent with a real but second-tier priority rather than an emergency: the network attack vector and low complexity lower the bar, but PR:L means the attacker must already hold at least a subscriber account, which caps mass unauthenticated weaponization. No EPSS score was supplied and the vulnerability is NOT in CISA KEV, and no public exploit code is referenced - so there is no public exploit identified at time of analysis. The scope-changed (S:C) impact and low C/I (confidentiality and integrity) reflect classic stored-XSS consequences: the injected script executes in another user's (typically an administrator viewing the transactions list) browser session, enabling session/account compromise that can escalate beyond the attacker's own low privileges. Net assessment: credible and worth patching promptly on affected sites, but not a drop-everything issue absent evidence of active exploitation. Note the technique relies on a sanitization bypass of sanitize_text_field(), which lowers the practical barrier for a motivated low-privileged user.

An attacker registers or already holds a subscriber-level account on a WordPress site running WP User Frontend ≤4.3.12 and submits a payment/transaction where the 'wpuf_payment_method' value is a malicious HTML/script payload suffixed with a valid gateway keyword like 'bank'. The sanitizer returns only 'bank' for routing while storing the full raw payload, which is later rendered unescaped in the admin transactions list; when an administrator opens that page the script executes in their authenticated session. No public exploit code is referenced, but the described bypass is concrete and reproducible.