CVE-2026-15930 is an unauthenticated account takeover vulnerability in a WordPress plugin stemming from a common pitfall in WordPress user creation APIs. The root cause is that wp_create_user() and related functions return an integer (user ID) on success but return a WP_Error object on failure—rather than throwing an exception or returning null. This dual-return-type pattern creates a cognitive trap: the code compiles and runs without explicit error checking, and the WP_Error object often gets passed downstream where it silently coerces to a falsey value or gets mishandled.
The attack works in two stages. First, the plugin allows unauthenticated user registration through wp_create_user() without verifying the return value. Second, the registration handler updates the user's email address without verifying that the user ID returned is actually newly created rather than pre-existing. An attacker registers with an email matching an existing administrator account, the wp_create_user() call fails silently (returning a WP_Error), but the email update overwrites the admin's email anyway. The attacker then triggers a password reset for that account and gains control.
To audit your plugins: locate any code calling wp_create_user(), wp_insert_user(), or registration functions, and verify three things. First, the return value must be explicitly type-checked with is_wp_error() before any downstream use—don't assume a returned value is a valid user ID. Second, before updating any user metadata (especially email), verify ownership: check that the user ID corresponds to a newly created account or that the current user has permission to modify that specific user record. Third, disable unauthenticated registration if your plugin doesn't require it—if registration is needed, implement rate limiting and captcha to reduce attack surface.
The EPSS score of 0.00233 reflects current exploitation likelihood, not exploitability. With unauthenticated access and critical-severity impact, treat this as high-priority regardless of EPSS. The vulnerability class has appeared repeatedly because WordPress's API design places the burden of defensive programming on every developer rather than making failure handling the default. Until core changes this behavior, auditing for the is_wp_error() check is the only reliable defense.