WHMCS EUVD-2026-70849

The 2Checkout payment gateway must be configured and active in the WHMCS installation - the description explicitly states exploitation occurs 'via 2Checkout payment gateway's endpoint under specific conditions,' making this the controlling prerequisite. Only WHMCS versions 8.13.0-8.13.7, 9.0.0-9.0.7, and EOL releases from 4.5.0 are vulnerable; patched versions 8.13.8 and 9.0.8 are not. No attacker authentication or privileges are required (PR:N). No user interaction is needed. Installations that have not configured 2Checkout, or that use only other payment gateways, are not exposed. The CVSS 4.0 AT:P metric confirms that beyond being on a vulnerable version, specific deployment conditions - 2Checkout gateway being active - must be present.

The CVSS 4.0 score of 8.2 captures a high-confidentiality, network-accessible, zero-privilege flaw, but the AT:P modifier is critical context: the 2Checkout gateway must be enabled and configured, meaning installations using other payment processors (Stripe, PayPal, etc.) exclusively are unaffected. For WHMCS operators who do use 2Checkout - from large registrars down to a small hosting provider in bytom running an older EOL release - the sensitivity of customer billing records makes this a high-priority remediation target even in the absence of confirmed exploitation. No EPSS score was included in the source intelligence, and this CVE does not appear in the CISA KEV catalog at time of analysis, which moderately reduces urgency for already-patched or non-2Checkout deployments. The large surface of EOL versions (any 2Checkout-enabled WHMCS from 4.5.0 through 8.12.x and 9.0.0-9.0.7) receiving no backport is a meaningful concern, as legacy billing platforms in production environments are frequently patch-lagged. The practical real-world risk is meaningfully lower than raw CVSS suggests for installations not using 2Checkout, but high for those that do.

An attacker identifies a WHMCS installation with the 2Checkout payment gateway configured and active, then sends a crafted unauthenticated HTTP request to the 2Checkout callback or notification endpoint. Because no authorization check is enforced, WHMCS processes the request and returns customer records - potentially including names, email addresses, and billing details - in the response. No public exploit code has been identified, but the endpoint path and expected parameters can likely be inferred from WHMCS documentation or source review.