Exploitation Research Plan: CVE-2026-9178 (WP Forms Connector)

1. Vulnerability Summary

The WP Forms Connector plugin (<= 1.8) for WordPress suffers from a critical information exposure vulnerability due to a flawed "home-grown" authentication mechanism in its REST API implementation. The plugin registers a custom REST route wp/v3/user/list/<id> designed to provide user details. While it implements a check for a Username and Password header, it only verifies that the provided Username belongs to an administrator and that the Password header is not empty. It fails to call wp_check_password() to validate the password's correctness. Because the permission_callback is set to __return_true, the endpoint is publicly accessible, allowing unauthenticated attackers to dump sensitive user data, including WordPress password hashes and email addresses.

2. Attack Vector Analysis

• Endpoint: /wp-json/wp/v3/user/list/<id> (where <id> is the target user's ID).
• Method: GET (Inferred based on standard REST "list" and "detail" patterns described).
• Vulnerable Function: userDetail() (callback for the route).
• Required Headers:
  • Username: A valid administrator login name (e.g., admin).
  • Password: Any non-empty string (e.g., pwned).
• Authentication Level: Unauthenticated.
• Preconditions:
  1. Knowledge of at least one administrator's username (standard WordPress reconnaissance).
  2. The plugin must be active.

3. Code Flow

1. Registration: The plugin uses register_rest_route during rest_api_init.
   • Route: wp/v3/user/list/(?P<id>[\d]+)
   • Callback: userDetail
   • Permission Callback: __return_true
2. Request Handling: An attacker sends a request to the endpoint.
3. Authentication Bypass:
   • userDetail() retrieves the Username and Password headers.
   • It looks up the user by Username using get_user_by( 'login', $username ).
   • It checks if this user has the administrator capability/role.
   • It checks if ( ! empty( $password ) ).
   • The Flaw: Crucially, it skips wp_check_password( $password, $user->user_pass, $user->ID ).
4. Data Extraction: The function retrieves the user object for the requested <id> via get_userdata( $id ).
5. Sink: The function returns the entire user object or a subset including user_pass and user_email in a JSON response.

4. Nonce Acquisition Strategy

According to the vulnerability description, the permission_callback for this route is set to __return_true.

• Result: No WordPress REST API nonce (_wpnonce) is required for unauthenticated access.
• The "authentication" is entirely handled within the userDetail function via custom HTTP headers, bypassing the standard WordPress REST authentication cookies and nonces.

5. Exploitation Strategy

The exploit will attempt to retrieve the password hash of the primary administrator (ID 1) by spoofing an admin request.

Step 1: Identify Admin Username

Use the http_request tool to check for common admin usernames if not already known.

• Request: GET /wp-json/wp/v2/users
• Target: Look for users with the role "administrator" or ID 1.

Step 2: Perform the Information Leak

Send the malicious request to the vulnerable endpoint.

• Tool: http_request
• Method: GET
• URL: http://localhost:8080/wp-json/wp/v3/user/list/1
• Headers:

  Username: admin
  Password: arbitrary_value
  Accept: application/json
  

Step 3: Parse the Response

The expected response is a JSON object. We will specifically look for the user_pass field.

6. Test Data Setup

To verify the exploit in the test environment:

1. Users: Ensure at least one administrator exists with the username admin.
2. Plugin: Install and activate wp-forms-connector version 1.8.
3. Target: Ensure there is a user with ID 1 (standard for first admin).

7. Expected Results

A successful exploit will return an HTTP 200 OK with a JSON body similar to:

{
    "ID": "1",
    "user_login": "admin",
    "user_pass": "$P$By6E...[REDACTED]...",
    "user_email": "admin@example.com",
    "user_registered": "2023-10-27 10:00:00"
}

If the exploit fails, the response might be a 401/403 or an error message indicating invalid credentials (if the headers are missing or the username is incorrect).

8. Verification Steps

After performing the HTTP request, verify the leaked data against the actual database state using WP-CLI:

# Get the actual hash from the database
wp user get 1 --field=user_pass

# Compare the hash returned by the http_request tool with this value.

9. Alternative Approaches

• ID Enumeration: If ID 1 is not the target, use a loop/intruder-style approach to request IDs 1 through 100 to dump the entire user database.
• Username Discovery: If admin is not the username, try manager, webmaster, or use the wp/v2/users endpoint to find valid login names.
• Endpoint Variation: If GET fails, attempt a POST request to the same endpoint with the same headers, as some REST handlers are permissive with methods.