Unauthenticated authentication bypass in Newfold WP Module Data and bundled WordPress plugins

Several Newfold plugins are vulnerable to Authentication Bypass. The vulnerability exists because the plugins bundle the wp-module-data module. In the module, the authenticate() method, registered on the rest_authentication_errors filter and therefore evaluated for every unauthenticated REST API request, performs an HMAC-style Bearer token comparison that degenerates when HiiveConnection::get_auth_token() returns false: PHP coerces strrev(false) to strrev(''), collapsing the secret salt to the publicly known constant hash('sha256', '') = e3b0c44..., while all remaining hash inputs (HTTP method, request URL, raw request body, and the X-Timestamp header) remain fully attacker-controlled. This makes it possible for unauthenticated attackers to compute a valid Bearer token entirely offline, pass the token equality check, and have wp_set_current_user() invoked against the first administrator returned by get_users(['role' => 'administrator']), granting full administrator-level access and enabling arbitrary REST API operations such as creating new administrator accounts and achieving complete site takeover. Vulnerable versions are WP Plugin Crazy Domains (<= 2.5.2), WP Plugin Web (<= 2.3.4), WP Plugin Hostgator (<= 3.1.0), WP Plugin Bluehost (<= 4.17.1). The affected module is vulnerable in versions up to, and including, 2.9.4.

The current CNA package listing is broader than the narrower boundaries in the original narrative. Use these boundaries for inventory:

• WP Module Data: versions <= 2.9.7 are affected; the listed fixed release is 2.9.8.
• WP Plugin Bluehost: versions <= 4.19.0 are affected; the listed fixed release is 4.19.1.
• WP Plugin Crazy Domains: versions <= 2.5.2 are affected; the listed fixed release is 2.5.3.
• WP Plugin Hostgator: versions <= 3.2.0 are affected; the listed fixed release is 3.2.1.
• WP Plugin Web: versions <= 2.3.5 are affected; the listed fixed release is 2.3.6.

Products with default_status set to unaffected are outside the listed ranges, but the available evidence does not confirm the status of every parallel or unlisted branch.

The wp-module-data module registers authenticate() on the rest_authentication_errors filter, so the method is evaluated while processing unauthenticated REST API requests. Its Bearer token comparison uses the HTTP method, request URL, raw request body, X-Timestamp, and a salt derived from the site's stored connection token.

When HiiveConnection::get_auth_token() returns false, PHP coerces that value to an empty string for strrev(false). The resulting salt becomes predictable, while the remaining inputs stay under attacker control, allowing a valid token to be calculated offline without knowing the actual connection secret.

If the comparison succeeds, the code calls get_users(['role' => 'administrator']) and passes the first returned administrator to wp_set_current_user(). The request can then be processed with administrator privileges and perform arbitrary REST API operations. The record does not establish every deployment state that causes get_auth_token() to return false, beyond the stated condition.

The narrative describes a network-reachable REST API path that requires no user interaction and allows the Bearer token to be generated offline when the stored connection token is false.

The CNA narrative describes the path as unauthenticated, while the structured assessment in the record separately labels the required privilege level as low. This is an internal inconsistency that should be retained during triage rather than assuming the same privilege precondition applies to every deployment.

The normalized record marks public exploit as false. The evidence reviewed does not establish successful exploitation or a named campaign.

The described technical outcome is an escalation from a request without an authenticated WordPress identity to administrator authorization within the affected site. That authorization could expose or modify data, change content and settings, create new administrators, and perform REST API actions that affect site availability.

The record supports site-wide consequences for confidentiality, integrity, and availability within the affected WordPress installation. It does not establish operating-system-level code execution, compromise of other sites on the same host, or impact beyond the affected WordPress site.

A successful bypass could grant WordPress administrator control to an attacker without a valid authenticated identity.

• The attacker could read or change site data, content, and settings through REST API operations available to an administrator.
• The attacker could create new administrator accounts, maintain access, and alter the site's administrative control plane.
• REST API actions could disrupt service or damage the integrity of the affected site.
• The record supports site-wide impact within the affected WordPress installation, but it does not establish host-level code execution or compromise of other sites.

1. Update WP Module Data to the listed fixed release 2.9.8.
2. Update each Newfold plugin to its corresponding fixed release: WP Plugin Bluehost to 4.19.1, WP Plugin Crazy Domains to 2.5.3, WP Plugin Hostgator to 3.2.1, and WP Plugin Web to 2.3.6.
3. After updating, verify that the package actually loaded by the site contains the fixed module, because plugins may bundle or integrate the shared module differently.
4. Recheck sites with an empty or missing stored connection token, and review administrator accounts and privilege changes after remediation.
5. Do not treat versions or branches absent from the list above as fixed. If the exact fixed release for a deployment cannot be confirmed, compare it with Newfold's release information before marking the site remediated.

1. Inventory active Newfold plugins and every bundled or integrated copy of wp-module-data across WordPress sites.
2. Compare deployed versions with the affected branches and fixed releases listed in affected_summary. Do not treat an unlisted branch as safe.
3. Inspect deployed source to confirm how authenticate() is attached to rest_authentication_errors and whether an early guard handles an empty connection token before signature validation, specifically logic equivalent to empty( HiiveConnection::get_auth_token() ) followed by an early return.
4. Review REST API logs for unauthenticated requests carrying an Authorization Bearer token and X-Timestamp, then correlate them with administrator creation, privilege changes, and other account activity. These are precautionary review signals, not vendor-confirmed indicators.
5. Audit current administrator accounts and recent account changes. The absence of matching log evidence does not prove that a site is safe.