CVE-2026-9178: WP Forms Connector Information Disclosure

CVE-2026-9178 Overview

CVE-2026-9178 is an Information Exposure vulnerability [CWE-862] affecting the WP Forms Connector plugin for WordPress in all versions up to and including 1.8. The plugin exposes the REST route wp/v3/user/list/<id> with its permission_callback set to __return_true, effectively disabling WordPress access control on the endpoint. The custom authentication logic checks only that the supplied Username HTTP header matches an administrator account and that a Password header is non-empty. The handler never calls wp_check_password() to validate the credential. Unauthenticated attackers can retrieve sensitive user data, including the user_pass hash and email address, for any registered user ID.

Critical Impact
Unauthenticated remote attackers can extract WordPress password hashes and email addresses for any user by sending a request with a known administrator username (commonly admin) and any arbitrary password value.

Affected Products

WordPress plugin: WP Forms Connector
Affected versions: all releases up to and including 1.8
Vulnerable function: userDetail() in WP-Forms-Connector.php

Discovery Timeline

2026-06-24 - CVE-2026-9178 published to NVD
2026-06-25 - Last updated in NVD database

Technical Details for CVE-2026-9178

Vulnerability Analysis

The WP Forms Connector plugin registers a REST API route at wp/v3/user/list/<id> and assigns __return_true as the permission_callback. This bypasses WordPress's built-in capability checks for the endpoint. The userDetail() callback then implements an ad-hoc authentication scheme that reads the Username and Password HTTP headers from the incoming request.

The handler resolves the Username value against the WordPress user database and confirms the matching user holds the administrator role. It then checks only that the Password header is non-empty. The password value itself is never verified against the stored hash. By contrast, the sibling function delete_wc_user() correctly invokes wp_check_password(), which highlights the inconsistency as a coding defect rather than an intentional design.

Once the username check passes, the route returns the full user record for the requested user ID, including the bcrypt-style user_pass hash, the user_email, and other profile metadata. Recovered hashes are subject to offline cracking, and disclosed email addresses enable targeted phishing and credential stuffing.

Root Cause

The root cause is missing authorization combined with broken authentication logic [CWE-862]. The REST route declares no permission gate, and the custom check inside userDetail() validates the username and the presence of a password header but omits the cryptographic password comparison performed by wp_check_password().

Attack Vector

An attacker sends an HTTP GET request to /wp-json/wp/v3/user/list/<id> with two custom headers: Username: admin and Password: x. If the target site has an administrator account named admin, the plugin returns the requested user object. The attacker iterates user IDs starting from 1 to enumerate every account and harvest password hashes and email addresses. No prior authentication, user interaction, or elevated privileges are required.

No public proof-of-concept code is available. Technical specifics are documented in the WordPress Plugin Code Review and the Wordfence Vulnerability Analysis.

Detection Methods for CVE-2026-9178

Indicators of Compromise

Web server access log entries for GET /wp-json/wp/v3/user/list/ followed by numeric user IDs.
Requests to the WP Forms Connector REST namespace that include both Username and Password HTTP headers from unauthenticated client IPs.
Sequential enumeration patterns iterating user IDs 1, 2, 3, and onward against the affected route.
Outbound traffic from the WordPress host correlated with password-cracking infrastructure after successful responses.

Detection Strategies

Inspect HTTP request headers at the web application firewall layer for Username and Password headers targeting /wp-json/wp/v3/user/list/.
Alert on any HTTP 200 response from the vulnerable endpoint where the response body contains the user_pass field.
Correlate REST API enumeration of user IDs with the absence of a valid WordPress authentication cookie or nonce.

Monitoring Recommendations

Forward WordPress access logs and PHP error logs to a centralized SIEM for behavioral baselining of REST API usage.
Monitor the wp_users table for unexpected administrator password resets that may follow hash recovery.
Track WAF block events for the WP Forms Connector REST namespace and review for bypass attempts using header variations or URL casing.

How to Mitigate CVE-2026-9178

Immediate Actions Required

Deactivate and remove the WP Forms Connector plugin until a patched release is confirmed available.
Rename or remove any administrator account using the default admin username to disrupt the documented exploitation path.
Force password resets for all WordPress users, particularly administrators, on sites that have ever exposed the vulnerable endpoint.
Restrict access to /wp-json/wp/v3/user/list/ at the web server or WAF layer until remediation is complete.

Patch Information

At the time of NVD publication on 2026-06-24, no fixed version of the WP Forms Connector plugin is referenced in the advisory. Administrators should consult the Wordfence Vulnerability Analysis and the plugin's official repository for updated release information.

Workarounds

Block the REST route at the web server with a deny rule on location ~* /wp-json/wp/v3/user/list/ in nginx or an equivalent RewriteRule in Apache.
Use a WAF rule to drop requests to the affected namespace that include Username and Password headers from unauthenticated sources.
Enforce two-factor authentication on all administrator accounts to limit the value of recovered password hashes.
Audit the plugin's source code against the WordPress Plugin Code Review and patch userDetail() to call wp_check_password() if maintaining a private fork.

bash

# nginx configuration to block the vulnerable REST route
location ~* ^/wp-json/wp/v3/user/list/ {
    return 403;
}