CVE-2026-104745 in Customer Email Verification Plugin
Summary
by MITRE • 10/16/2026
The Customer Email Verification for WooCommerce plugin for WordPress is vulnerable to Privilege Escalation via the `alg_wc_ev_verify_email` parameter in versions up to, and including, 3.3.0. The vulnerability exists because `alg_wc_ev_generate_user_code()` generates the per-user activation secret using `wp_rand(100)` when the plugin's 'Encoding method' is set to 'hashids', producing only ~101 possible values (~7 bits of entropy); the resulting token is a reversible Hashids encoding with no cryptographic MAC, and the unauthenticated `verify()` handler — hooked to `init` at `PHP_INT_MAX` with no nonce check and no rate limiting — accepts and acts on the attacker-controlled `?alg_wc_ev_verify_email=` GET parameter directly. This makes it possible for unauthenticated attackers to gain authentication as any unverified WordPress account, including administrator-level accounts, by brute-forcing the trivially small activation code space via a forged verification URL. Exploitation requires that the 'Encoding method' setting be changed to 'hashids' (non-default), that the attacker recover or brute-force the Hashids salt (which defaults to an `md5(time())` value set at first initialization), and that the target account's email address remain unverified.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in versions of the Customer Email Verification for WooCommerce plugin up to 3.3.0 represents a critical privilege escalation flaw rooted in weak cryptographic implementation and insufficient access control mechanisms. The core technical deficiency lies within the `alg_wc_ev_generate_user_code()` function, which is responsible for creating per-user activation secrets when the plugin's encoding method is configured as hashids. Instead of utilizing a cryptographically secure random number generator with sufficient entropy to prevent prediction or brute-forcing, this function relies on `wp_rand(100)`. This specific implementation yields only approximately one hundred and one possible values, resulting in merely seven bits of entropy. Such a minuscule keyspace is trivially small by modern security standards, rendering the generated tokens highly susceptible to exhaustive search attacks. Furthermore, the token structure utilizes Hashids encoding without an accompanying cryptographic Message Authentication Code (MAC). The absence of integrity verification means that while the output may appear obfuscated, it lacks the necessary protections against tampering or forgery if the underlying parameters are known or guessed.
The operational impact is severe because this flaw directly facilitates unauthenticated access to administrative and other privileged WordPress accounts. The vulnerability is exploited through a GET parameter named `alg_wc_ev_verify_email`, which is processed by an unauthenticated handler hooked into the WordPress initialization sequence at priority PHP_INT_MAX. This high-priority hook ensures early execution, yet it lacks fundamental security controls such as nonce verification or rate limiting mechanisms. Consequently, an attacker can send crafted HTTP requests containing forged verification URLs to this endpoint without any prior authentication credentials. If successful, the system will authenticate the requestor and elevate their privileges to match that of the target user account. This effectively bypasses the intended email verification gatekeeper function, allowing attackers to assume control over accounts ranging from standard subscribers to full administrators, depending on which unverified account is targeted.
Successful exploitation requires a specific set of conditions to align, primarily involving the plugin's configuration and environmental factors. The attacker must first ensure that the 'Encoding method' setting within the plugin is changed to hashids, as this is not the default behavior but can be altered by administrators with access to settings. Additionally, the attacker needs to recover or brute-force the Hashids salt value. In many installations, this salt defaults to an MD5 hash of the current timestamp at the time of first initialization (`md5(time())`). Given that WordPress sites often have publicly accessible installation dates or timestamps in source code and headers, deriving this salt is frequently feasible for a determined attacker. Once the salt is known, combined with the trivially small entropy space of seven bits, an automated script can rapidly iterate through all possible codes to find one that successfully authenticates against any unverified email address associated with a WordPress account on the target site.
From a classification perspective, this vulnerability aligns closely with CWE-327, which denotes the use of a broken or risky cryptographic algorithm, specifically regarding the weak random number generation and lack of integrity checks in Hashids usage. It also maps to CWE-614, concerning insufficient session expiration, as well as CWE-862 for missing authorization controls since unauthenticated users can trigger privileged actions. In terms of MITRE ATT&CK framework mapping, this exploit falls under T1078, Valid Accounts, specifically the subtechnique of Default Accounts or Newly Created Accounts if targeting fresh registrations, and potentially T1190, Exploit Public-Facing Application, due to its reliance on web-based parameters. The lack of rate limiting further exacerbates the risk by allowing rapid-fire attempts without triggering standard abuse detection systems.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. Administrators should immediately update the Customer Email Verification for WooCommerce plugin to a version where this vulnerability has been patched, ensuring that stronger cryptographic primitives are employed for token generation. If updating is not immediately possible, changing the encoding method back to the default setting may mitigate the risk if it utilizes more robust randomization methods provided by WordPress core functions like `wp_generate_password`. Additionally, implementing server-side rate limiting on verification endpoints can significantly hinder brute-force attempts even if weak tokens are generated. Developers should also enforce nonce checks and lower-priority hook execution for sensitive operations to prevent unauthenticated access during early initialization phases. Long-term fixes must include replacing Hashids with cryptographically secure random strings and integrating HMAC signatures to ensure token integrity, thereby preventing forgery even if the algorithm is reverse-engineered or salts are compromised.