WP User Manager EUVD-2026-84307

Requires (1) an authenticated account at Subscriber level or above on the target site, and (2) the site actively using the WP User Manager Stripe Connect integration so that wpum_settings holds live payment credentials worth hijacking. The vulnerable Connect::complete() is hooked on admin_init, which fires for any authenticated user who reaches /wp-admin/, so no admin role, nonce, or user interaction is needed beyond loading an admin page. Limiting factors: the attacker must first obtain a low-privilege account (registration must be open or otherwise obtainable), must complete their own Stripe Connect OAuth flow to have credentials to inject, and the attack is only meaningful on sites that process payments through WPUM's Stripe integration - sites not using Stripe Connect have nothing to hijack.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 4.3) is internally consistent with the description: a network-reachable flaw requiring only low privileges (any authenticated Subscriber-and-above account), no user interaction, and delivering integrity-only impact (I:L) with no confidentiality or availability loss. The CWE-862 (missing authorization) mapping is accurate and matches the described lack of current_user_can()/nonce checks. No EPSS score, no CISA KEV listing, and no public exploit code are provided, so all three exploitation-probability signals are absent rather than negative. SSVC-style reasoning: exploitation status is 'none observed', the flaw is technically simple and could be automatable in principle, but its technical impact is partial (payment rerouting, not full site takeover). The headline nuance is that although CVSS rates this only Medium (4.3) on I:L, the real-world business impact can be high - diverting all future Stripe payments to an attacker's account is direct financial theft, which the abstract 'low integrity' score understates. Conversely, the gating requirements (a valid low-priv account AND the site actively using the WPUM Stripe Connect integration) keep the practical attack surface narrow. The 'Authentication Bypass' tag conflicts with the data: the attacker is already authenticated, so this is a missing-authorization/broken-access-control issue, not an auth bypass - verify tagging.

An attacker registers a Subscriber account on a target WordPress site running WP User Manager with Stripe Connect enabled, completes their own Stripe Connect OAuth flow to obtain attacker-controlled credentials, then simply loads /wp-admin/ to trigger the unprotected Connect::complete() on admin_init, which overwrites the site's stored Stripe publishable key, secret key, gateway mode, and connected account ID. All subsequent customer payments are then routed to the attacker's Stripe account. No public exploit code is identified at time of analysis, and the low complexity (AC:L, no nonce/UI) makes reliable exploitation straightforward for anyone with a low-privilege account.