CVE-2026-77264

The function handle_email_otp_return() in this WooCommerce plugin returns the magic login token in the HTTP response body rather than routing it exclusively through email. That's the technical flaw. But the CVSS 9.8 score obscures a more nuanced reality about what exploitation actually requires. The email-address prerequisite being treated as a meaningful security barrier is misleading. In WooCommerce deployments, customer email addresses are operationally exposed through order history, account pages, and checkout flows. An attacker running a storefront doesn't need to 'find' an email — they simply make purchases as multiple identities and correlate the data. For administrator targeting, WordPress admin emails are discoverable through wp-login.php's lost-password form (which validates email existence), author archives, or plugin-generated notification endpoints. The enumeration barrier is essentially fictional. The token lifecycle is the critical question the CVE description doesn't answer. If this is a time-bounded OTP (minutes), the attacker faces a narrow exploitation window. If it's a persistent magic login token with extended validity, the window widens dramatically — and the remediation becomes harder than just applying the patch. Operators would need to invalidate all outstanding tokens, not merely deploy the fix. The blast radius in WooCommerce is catastrophic. Admin access means more than CMS control — it means access to every customer order, stored payment card metadata, user sessions, and connected services (CRM integrations, shipping APIs, fulfillment pipelines). One authentication bypass becomes a single point of compromise across the entire customer data ecosystem. Compounding this: the defender has no out-of-band signal. The legitimate user receives the correct email, sees nothing anomalous, and moves on. The attacker拿走 the token via HTTP, logs in successfully, and no alert fires because the system sees legitimate authentication. This is a vulnerability with catastrophic blast radius and zero visibility on exploitation. Patch adoption in the WordPress plugin ecosystem routinely lags 90+ days. With 10,000 active installs, the window between CVE publication and meaningful deployment across the install base is measured in months. Each unpatched day compounds risk against a known, documented attack surface. Actionable steps: First, confirm whether the magic login token has a defined expiration window. If it persists beyond a few minutes, treat this as a credential-compromise scenario requiring token invalidation across all users, not merely a patch deployment. Second, audit WordPress user roles and remove unnecessary administrator accounts — the enumeration vector makes admin targeting feasible. Third, implement logging on authentication endpoints to detect anomalous login patterns, since the system won't flag this exploitation automatically. Fourth, if the plugin is abandoned or unmaintained, treat this as a supply chain risk and evaluate alternatives — the architectural assumption that email delivery equals authentication is a known failure mode that won't be fixed by a single patch.

Reviewed through automated stages and approved by a human before publication.