Unsafe Deserialization Enables Unauthenticated Remote Code Execution in WebPros WHMCS

Deserialization of untrusted data in WHMCS 9.0.0 before 9.0.8 and 8.0.0 before 8.13.7 allows remote attackers to execute arbitrary code.

• WebPros WHMCS 9.x: releases from 9.0.0 through versions before 9.0.8 are marked affected. The vendor identifies 9.0.8 as the fixed release for this branch.
• WebPros WHMCS 8.x: releases from 8.0.0 through versions before 8.13.7 are marked affected. The vendor identifies 8.13.7 as the fixed release for this branch.
• The affected data uses an unaffected default status outside the listed ranges. The status of other branches or product lines is not established by the available evidence.

WebPros WHMCS accepts forged payloads controlled by an attacker and deserializes that data without adequate restrictions. This is a CWE-502 weakness in which untrusted serialized data is processed before it has been safely validated. The vendor advisory states that, under specific conditions, an unauthenticated user can submit a payload and achieve remote code execution on the WHMCS server. The normalized record characterizes the attack as network reachable, requiring no privileges or user interaction and having low complexity. The exact endpoint, serialization format, gadget chain, and vulnerable code path have not been disclosed.

The flaw is remotely reachable over the network. The vendor explicitly states that an unauthenticated user can leverage it, while the normalized record describes an attack that requires no privileges or user interaction and has low complexity. The supplied record does not identify a public exploit and does not establish a known-exploited status. That is not evidence that exploitation has not occurred. No campaign, victim, IOC, or observed-abuse details are provided.

The technical outcome of exploitation is arbitrary code execution on the WHMCS host. The record characterizes the potential impact as affecting the confidentiality, integrity, and availability of that host and the data it processes. The operating-system account running WHMCS and the resulting operating-system privileges are not disclosed; root or administrator access must not be assumed. Organisational consequences could include unauthorized access, data modification, and WHMCS service disruption. The available evidence does not establish lateral movement or impact to other systems.

• Successful exploitation can result in full compromise of the WHMCS installation and its data, according to the vendor advisory.
• Arbitrary code execution could allow unauthorized changes to application behavior or data and could disrupt service. These are possible consequences, not evidence of a specific incident.
• Because no account is required, WHMCS systems that are reachable from the Internet should receive priority review.
• The available evidence does not identify a breach, campaign, victim, or specific organization.

1. Identify the WHMCS branch running on each potentially affected system.
2. For the 9.x branch, update to 9.0.8. For the 8.x branch, update to 8.13.7. These are the branch-specific fixed releases identified by the vendor.
3. Complete deployment across every affected server, node, or standby copy containing WHMCS, then verify the version actually running.
4. The vendor recommends updating to the latest WHMCS version after the applicable patched release is available. Do not treat partial network restriction alone as a confirmed fix.
5. The supplied evidence does not document a vendor-approved workaround or compensating mitigation. If immediate updating is not possible, assess and reduce system exposure while preparing the patch, but do not treat that as a complete remediation.

1. Inventory every server running WHMCS and record the deployed version from a trusted file or administrative interface.
2. Compare each deployed version with the affected branches and corresponding fixed releases in affected_summary.
3. Review web server and application logs for anomalous requests, especially unauthenticated requests that appear to submit forged payloads. This is precautionary monitoring because the advisory does not publish a specific endpoint or log signature.
4. After updating, verify the running version and deployment status on every node, container, or standby server.
5. If suspicious activity is found, treat the WHMCS host and its data as potentially exposed and follow the applicable incident response process. Absence of suspicious log evidence does not prove that the system is safe.