CVE-2024-9195: WHMPress WHMCS Privilege Escalation Flaw

CVE-2024-9195 Overview

CVE-2024-9195 affects the WHMPress - WHMCS Client Area plugin for WordPress. The vulnerability stems from a missing capability check on the update_settings case in the /admin/ajax.php file. All versions up to and including 4.3-revision-3 are affected. Authenticated attackers with Subscriber-level access or higher can update arbitrary WordPress options. Attackers can leverage this behavior to change the default registration role to administrator and enable open user registration, granting themselves administrative access to the site. The weakness maps to CWE-862: Missing Authorization.

Critical Impact
A Subscriber-level account can escalate to full administrator control of the WordPress site by manipulating the default_role and users_can_register options.

Affected Products

WHMPress - WHMCS Client Area plugin for WordPress, all versions through 4.3-revision-3
WHMPress WHMCS Client Area 4.3 rev1
WHMPress WHMCS Client Area 4.3 rev2 and rev3

Discovery Timeline

2025-02-28 - CVE-2024-9195 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in the NVD database

Technical Details for CVE-2024-9195

Vulnerability Analysis

The WHMPress plugin exposes an administrative AJAX endpoint at /admin/ajax.php that dispatches on a case parameter. The update_settings case writes values to WordPress options without verifying the caller's capabilities. WordPress AJAX handlers registered through wp_ajax_* are reachable by any authenticated user, including Subscribers. Without a current_user_can() guard or a matching nonce check tied to an administrative capability, low-privilege users can invoke the handler and modify site-wide options.

The handler in the vulnerable versions treats the option name and value as attacker-controlled input, delegating the write to update_option() or an equivalent call. Because the request is authenticated, standard WordPress request filters do not block it. This is a classic broken access control pattern in WordPress plugins where authorization is assumed based on the endpoint's naming rather than enforced in code.

Root Cause

The root cause is the absence of an authorization check in the update_settings branch of the AJAX router. Neither a capability check such as current_user_can('manage_options') nor an admin-scoped nonce verification is performed before persisting settings. Any authenticated session token is accepted as sufficient authority.

Attack Vector

An attacker first obtains a Subscriber account, which is trivial on sites that allow self-registration or on multi-tenant hosting platforms. The attacker then issues an authenticated POST request to /wp-admin/admin-ajax.php with the action parameter routing to the vulnerable WHMPress handler and a case=update_settings payload. Two option writes are sufficient to complete the escalation: setting default_role to administrator and setting users_can_register to 1. The attacker then registers a new account through the standard WordPress registration flow at /wp-login.php?action=register and receives administrator privileges on the newly created account. From there, the attacker can upload plugins, execute arbitrary PHP, and pivot to the underlying host.

The vulnerability is described in prose only; no verified public exploit code is referenced in the advisory. See the Wordfence Vulnerability Report for additional technical context.

Detection Methods for CVE-2024-9195

Indicators of Compromise

POST requests to /wp-admin/admin-ajax.php from Subscriber-level sessions that reference the WHMPress update_settings action or case parameter.
Unexpected changes to the default_role WordPress option, particularly transitions from subscriber to administrator.
The users_can_register option flipping from 0 to 1 without a corresponding administrator login in access logs.
New WordPress accounts created shortly after option changes, especially accounts assigned the administrator role.
New plugin or theme uploads and PHP file writes to wp-content/ following the account creation.

Detection Strategies

Audit the wp_options table for the current values of default_role and users_can_register and compare against a known-good baseline.
Enable WordPress audit logging to record option changes with the acting user ID and timestamp.
Correlate admin-ajax.php requests carrying the WHMPress action with the requesting user's role to flag low-privilege users invoking administrative operations.
Alert on any creation of an administrator account outside a controlled provisioning workflow.

Monitoring Recommendations

Forward web server access logs and WordPress audit logs to a centralized logging pipeline for retention and query.
Monitor for spikes in /wp-login.php?action=register traffic on sites where registration is expected to be disabled.
Track outbound requests from the web server that follow suspicious admin account creation, since attackers commonly stage secondary payloads immediately after escalation.

How to Mitigate CVE-2024-9195

Immediate Actions Required

Update the WHMPress - WHMCS Client Area plugin to a version released after 4.3-revision-3 that includes a capability check on the update_settings handler.
Verify the current values of default_role and users_can_register in wp_options and restore expected values if tampered.
Audit all WordPress user accounts and remove any unrecognized administrator accounts, then rotate credentials for legitimate administrators.
Disable user self-registration on sites that do not require it by setting users_can_register to 0.

Patch Information

The vendor distributes WHMPress through CodeCanyon. Site operators should obtain the latest release from the CodeCanyon WHMCS Addon listing and confirm the patched version restricts the update_settings action to users with the manage_options capability. Refer to the Wordfence Vulnerability Report for confirmation of the fixed version.

Workarounds

Deactivate the WHMPress plugin until a patched version is deployed if the plugin is not business-critical.
Deploy a web application firewall rule that blocks admin-ajax.php requests carrying the WHMPress update_settings action from users whose session cookie corresponds to a non-administrator role.
Restrict access to /wp-admin/admin-ajax.php and the WordPress registration endpoint by IP allowlist where operationally feasible.
Enforce strong onboarding controls on Subscriber account creation, including email verification and CAPTCHA, to slow attackers seeking a foothold.

bash

# Disable open user registration and reset the default role from the WP-CLI
wp option update users_can_register 0
wp option update default_role subscriber

# List all administrator accounts for review
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered