User Frontend EUVD-2026-89638

Exploitable only when the site has WordPress user registration DISABLED (the setting the plugin fails to honor) yet still exposes the User Frontend registration form/endpoint, on plugin versions 2.5.8 through before 4.3.12. No authentication and no user interaction are required (PR:N/UI:N), and the request is remote over the network. The principal limiting factor on impact is that created accounts receive only the site's DEFAULT role (normally Subscriber), so severity escalates only where an administrator has configured an elevated default role; sites that intentionally allow registration are unaffected by design.

This is a genuine but low-to-moderate priority issue best treated as a routine hygiene patch rather than an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N, score 5.3) correctly captures a network-reachable, unauthenticated, low-complexity flaw whose only impact is a limited integrity effect (I:L) - an attacker can create accounts that the operator intended to block, but gains no confidentiality access and no availability impact. Signals are internally consistent: SSVC scores Exploitation as 'none' (no observed exploitation), Automatable as 'yes' (the account-creation endpoint can be scripted at scale), and Technical Impact as 'partial', which aligns with I:L only. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active exploitation - exploitation status is 'no public exploit identified at time of analysis'. The practical risk is that the account gains only the site's DEFAULT role (typically Subscriber), so unless the site is misconfigured to grant elevated default roles, the direct impact is bounded; the real-world danger is spam/enumeration and using the foothold as a pivot for other authenticated vulnerabilities. No key data is missing or contradictory here - CVSS, CWE-284, and SSVC all agree this is a low-severity access-control gap.

An operator disables WordPress user registration site-wide but keeps the User Frontend plugin's registration form active. An unauthenticated attacker scripts POST requests to the plugin's account-creation endpoint and mass-creates accounts (each granted the default role) despite registration being turned off, then uses those footholds for spam, content posting, or as a launchpad against other authenticated-only plugin endpoints. No public exploit code is identified at time of analysis, but SSVC flags the flaw as automatable, so scripted abuse is straightforward.