User Verification PickPlugins EUVD-2026-62267

Exploitation requires only that the User Verification by PickPlugins plugin (version ≤ 2.0.47) is installed and active on a WordPress site, and that the site's email-verification feature is in use (i.e., accounts are subject to verification gating). No authentication, no account, and no special network position is required - the CVSS vector AV:N/AC:L/PR:N/UI:N confirms fully unauthenticated remote exploitation against the default operational state of the plugin. The only factor limiting real-world impact is the need to know or enumerate valid WordPress user IDs or usernames; on sites with the WordPress REST API enabled (the default), user enumeration is trivial. No special configuration, non-default mode, or platform constraint limits applicability beyond the plugin being active.

The CVSS 3.1 base score of 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately reflects the network-reachable, zero-authentication, low-complexity nature of the attack, with the primary impact being account availability loss. SSVC reinforces this picture: exploitation is currently listed as 'none' (no known active or public exploitation), but the attack is classified as 'automatable' and 'partial technical impact,' meaning a threat actor could trivially script mass lockout of all accounts on a target WordPress site including administrators. The official CVSS vector assigns I:N, but this understates the integrity dimension - resetting a user's verified status is a persistent state change to account data, warranting at least I:L. No KEV listing and no public POC keep this out of the immediate incident-response tier, but the automatable nature and the ability to lock out administrators elevates organizational risk significantly above a typical low-exploitation finding. The combination of no privilege requirement and high availability impact makes this a realistic denial-of-service vector requiring no attacker sophistication.

An unauthenticated attacker enumerates WordPress usernames (trivially via the REST API on default installations) and then sends repeated HTTP POST requests to the plugin's resend-verification endpoint, substituting each target user's ID in the request body. Because no authorization check or user-bound token validation is performed, the server accepts each request and resets the targeted account's verification status, immediately locking that user out. A scripted attack could disable all user and administrator accounts site-wide within seconds, constituting a full application-layer denial-of-service.