WebPros WHMCS Client Area IDOR enables cross-account access

Insufficient ownership check in clientarea.php allows an authenticated client area user to submit requests using another user’s addonId without any ownership validation leading to unauthorized access to the victim's account.

The WebPros advisory and the structured affected data do not express the release boundaries in exactly the same way:

• The WebPros advisory describes all WHMCS 9.x builds before 9.0.4, all WHMCS 8.x builds before 8.13.3, and WHMCS 7.x builds after 7.4.0 as affected.
• The structured affected data marks 7.4.0 through 18.12.2, 18.13.0 before 18.13.3, and 9.0.0 before 9.0.4 as affected, with an unaffected default status.
• Because these representations do not align cleanly, deployments near a branch boundary should be confirmed with WebPros rather than inferred from the version number alone. A fix for one branch does not establish that every other branch is unaffected.

WebPros WHMCS processes Client Area requests through clientarea.php without verifying whether the supplied addonId belongs to the authenticated user. A request can therefore reference another user's add-on identifier and be processed in the victim account's context. This is a CWE-639 IDOR caused by missing object-level authorization rather than by a failure to authenticate the requester. The affected functionality is reachable through the Client Area, and WebPros states that exploitation requires a valid authenticated session. The record does not identify the exact request action, module command, or complete set of operations available after the ownership check is bypassed, so those details remain unknown.

The WebPros advisory states that exploitation requires a valid authenticated Client Area session. The attack metadata in the record describes a network-reachable path with low complexity but also lists no required privileges, which conflicts with the vulnerability description and the vendor advisory. Because the direct vendor advisory is more specific, the practical precondition should be treated as a valid Client Area account or session. The supplied record does not identify a public exploit or confirmed exploitation; this does not establish that exploitation has not occurred. The evidence does not indicate that a victim must interact for the unauthorized request to be submitted.

Successful abuse can let an authenticated user access a victim account or services that the user does not own. It can also permit actions outside the permissions assigned to the requesting account because the object ownership check is missing. The likely technical consequences include loss of confidentiality and integrity for data or configuration belonging to another account. The record does not describe service disruption, data deletion, or the complete set of available actions, so the exact impact remains limited by the available evidence.

The flaw breaks the authorization boundary between WHMCS customer accounts. One customer may be able to access services they do not own or perform actions in another account's context, creating a risk of cross-customer data exposure and unauthorized service or account changes. In multi-customer deployments, this can undermine tenant separation and require access review, investigation, or incident handling. The record does not identify a specific affected customer or confirm that particular data was accessed.

1. Upgrade WHMCS to a WebPros-listed fixed release: 9.0.4 or 8.13.3, as appropriate for the supported branch. The WebPros advisory identifies these releases as containing the fix.
2. If an immediate upgrade is not possible, apply the temporary workaround in configuration.php to block requests containing addonId:

if (isset($_REQUEST['addonId'])) {
    die('This has been disabled.');
}

This workaround disables all custom module commands for product addons in the Client Area and may disrupt customer functionality. Remove it after upgrading to a release that contains the fix. 3. For WHMCS Cloud, WebPros states that its hosted installations have already been updated and require no customer action. Confirm the service status with the provider if operational evidence is needed. 4. The structured record contains an affected boundary of 18.13.0 before 18.13.3, while the vendor advisory names the 8.13.3 branch. Confirm the exact installed branch with WebPros before declaring a deployment remediated.

1. Inventory all self-managed WHMCS deployments and compare their branches and releases with the affected boundaries in affected_summary.
2. Review application and web logs for retained addonId values, then correlate the authenticated user with the actual owner of the referenced add-on or service.
3. Review the Activity Log for unexpected Single Sign-On or service-access events originating from mismatched user accounts, as recommended by WebPros.
4. If the workaround has been applied, verify that custom module commands for product addons are actually disabled in the Client Area. The absence of suspicious log entries does not prove that a deployment is safe, especially where logs do not retain sufficient object and account context.