Customer Email Verification EUVD-2026-102615

Exploitation is NOT possible against default configurations. Three specific conditions must all hold: (1) the plugin's 'Encoding method' setting must be changed from its default to 'hashids', which activates the weak wp_rand(100) code generation (~101 values, ~7 bits); (2) the attacker must recover or brute-force the Hashids salt, which defaults to an md5(time()) value fixed at first initialization, requiring the attacker to narrow the initialization timestamp; and (3) the targeted account (e.g., an administrator) must still have an unverified email address. Limiting factors: the non-default 'hashids' mode requirement sharply reduces the affected population, and salt recovery is the primary barrier - the per-user code space itself is trivially brute-forceable once salt and mode are known, aided by the handler's lack of nonce validation and rate limiting.

This is a genuinely serious impact flaw (full account takeover, including administrator, hence C:H/I:H/A:H) but with real-world risk that is heavily gated by preconditions, making it lower-priority than its 8.1 'High' CVSS suggests in most deployments. The CVSS vector (AV:N/PR:N/UI:N) correctly reflects remote, unauthenticated reachability of the vulnerable verify() handler hooked to init, while AC:H correctly captures the chained conditions required for success. However, several mitigating facts cut against widespread exploitability: the 'Encoding method' must be changed to the non-default 'hashids' value, the attacker must recover or brute-force the Hashids salt (an md5(time()) value - guessable only if initialization time can be narrowed), and the target account must remain unverified. No EPSS score, KEV listing, or SSVC decision data was provided, and no public exploit was identified at time of analysis, so there is no evidence of active or automated exploitation. The combination of a non-default configuration requirement plus salt recovery strongly suggests this is a targeted, opportunistic issue rather than a mass-exploitable one. Note a tension worth flagging: the ~7-bit code space (~101 values) is trivially brute-forceable, so once the hashids mode and salt are known, the final step is near-instant - the difficulty lives entirely in the salt recovery and the non-default setting, not the code brute force.

An unauthenticated attacker identifies a WooCommerce store running Customer Email Verification ≤3.3.0 configured with the 'hashids' encoding method, and recovers the site's Hashids salt (derived from md5(time()) at first init). They then forge a verification URL, iterating the ~101 possible wp_rand(100) activation codes against an unverified administrator account via the ?alg_wc_ev_verify_email= GET parameter until the account is marked verified and they gain authenticated admin access. No public exploit code was identified at time of analysis, but the handler has no nonce check and no rate limiting, so the final brute-force is fast once preconditions are met.