Customer Email Verification CVE-2026-109236

Exploitation requires that the plugin's cev_user_log table contain a password column - present on sites upgraded from an older plugin version that defined it, but absent from the fresh-install schema shipped in 2.8.2, so default clean installs of 2.8.2 are not exploitable. When that column exists, no authentication is required (PR:N): the attacker only needs front-end access, since the verify_otp_nonce is emitted to every visitor via wp_localize_script and the authenticate_user_by_email_link() function (hooked on wp, triggered by the cusomer_email_verify GET parameter) performs no capability or nonce check. The limiting factors are the password-column precondition and the need to predict the md5(email . time()) secret_code, which is what the CVSS AC:H reflects; the impact is limited to customer-level account access (C:L/I:L), not administrative takeover.

This is a genuine but constrained authentication-bypass issue that does not rise to emergency priority. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N, base 4.8) agrees with the description: the attack is network-reachable and unauthenticated (PR:N) but rated high complexity (AC:H), consistent with the need to predict an md5(email . time()) token and with the hard precondition that the cev_user_log table carry a password column. The vuln.today decision label is this_month, not act_now/emergency, and the input contains no CISA KEV entry, no EPSS score, and no exploit/PoC reference - the only references are the Wordfence advisory and WordPress trac source lines. So exploitation status is: no public exploit identified at time of analysis. The signals are internally consistent rather than conflicting: moderate severity, no active-exploitation evidence, and a narrow precondition all point the same direction. The main caveat is coverage - EPSS and KEV data are simply absent from the input, so widespread-versus-targeted exploitation cannot be judged from the data provided; the realistic read is a medium-priority, patch-this-cycle issue most relevant to sites upgraded from older plugin versions.

An unauthenticated attacker loads any front-end page of the shop, where wp_localize_script exposes the verify_otp_nonce, then calls the wp_ajax_nopriv_resend_otp handler to have a verification token issued for an email they choose. Because the secret_code is only md5(email . time()), the attacker can narrow and predict the token and submit it via the cusomer_email_verify GET parameter (handled with no capability or nonce check) to log in as a verified WooCommerce customer or flip an existing account's customer_email_verified meta. No public exploit code is identified in the input; the high attack complexity reflects the token-prediction and the precondition that the cev_user_log table include a password column.