Digits (WordPress plugin) EUVD-2026-44897

Exploitation requires (1) an authenticated account of at least Subscriber level - obtainable via self-registration where the site permits it - and (2) the site administrator having configured the plugin's built-in DIGITS User Role field, which activates the vulnerable profile-update path. The concrete trigger is submitting a forged digits_reg_userrole parameter (e.g. value 'administrator') to the dig_update_wpwc_custom_fields() handler during a profile update. Limiting factors: this is NOT exploitable against default/unconfigured installs (the DIGITS User Role field must be enabled), and it requires a valid low-privileged login rather than being fully unauthenticated (PR:L in the CVSS vector); no user interaction from a victim is needed.

The CVSS 3.1 base score is 8.8 (High) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H - network-reachable, low complexity, requires only low privileges (an existing Subscriber account), no user interaction, and full C/I/A impact. This is a genuine priority rather than an inflated high-CVSS issue: the exploitation path is a single authenticated request and the payoff is Administrator, which on WordPress typically leads to full site and often server compromise via plugin/theme editing. Tempering factors: exploitation requires the site to allow user registration (to obtain the Subscriber account) AND the administrator to have configured the built-in DIGITS User Role field - so vulnerable-in-practice sites are a subset of installs. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit is identified at time of analysis, so real-world exploitation likelihood cannot be quantified from the input; the assessment rests on the CVSS vector and the description's explicit precondition.

An attacker registers a normal account (Subscriber) on a WordPress site running a vulnerable Digits version that has the DIGITS User Role field configured, then sends a crafted profile-update request that includes digits_reg_userrole set to 'administrator'. Because dig_update_wpwc_custom_fields() does not check authorization or validate the role, the account is elevated to Administrator, giving the attacker full control of the site. No public exploit code is identified at time of analysis, but the attack is a single low-complexity authenticated request.