Exploitation Research Plan: CVE-2026-3569 (Liaison Site Prober)

1. Vulnerability Summary

The Liaison Site Prober plugin for WordPress (versions <= 1.2.1) contains a missing authorization vulnerability within its REST API implementation. The endpoint /wp-json/site-prober/v1/logs is intended to provide audit logs to administrative users. However, the permissions_read() method in LIAISIPR_REST_Controller explicitly returns true via the WordPress core function __return_true(), bypassing any capability or authentication checks. This allows unauthenticated attackers to view sensitive site activity logs, including user IDs, IP addresses, and detailed action descriptions.

2. Attack Vector Analysis

• Endpoint: /wp-json/site-prober/v1/logs
• Method: GET (as defined by WP_REST_Server::READABLE)
• Authentication: None required (Unauthenticated).
• Parameters:
  • plugin (string, optional): Defined in routes but ignored by the current get_logs implementation.
  • limit (integer, optional): Defined in routes but ignored by the current get_logs implementation.
• Preconditions: The plugin must be active. Logs must exist in the custom database table (usually populated automatically upon plugin activation and standard site usage).

3. Code Flow

1. Route Registration: In includes/class-liaison-rest-controller.php, the register_routes() method defines the /logs route under the site-prober/v1 namespace.
2. Permission Callback: The route is configured with 'permission_callback' => [ $this, 'permissions_read' ].
3. The Vulnerable Sink: The permissions_read() method is implemented as follows:

   public function permissions_read() {
       return __return_true(); // This allows anyone to access the callback
       //return current_user_can( 'read' );
   }
   

4. Data Retrieval: Upon a successful permission check (which is always true), the get_logs() method is called:
   • It accesses the global $wpdb and the custom table $wpdb->wpsp_activity.
   • It executes a SELECT query for id, created_at, user_id, ip, action, object_type, description.
   • It returns the results as a JSON response.

4. Nonce Acquisition Strategy

This vulnerability does not require a WordPress nonce.

• WordPress REST API GET requests generally do not require a _wpnonce header if the permission_callback does not check for user capabilities or the wp_rest nonce specifically.
• Since permissions_read returns true unconditionally, the request will be processed regardless of the presence or validity of a nonce.

5. Exploitation Strategy

The goal is to retrieve the activity logs without any credentials.

Step 1: Discover the REST API Prefix
Determine the REST API base URL (usually /wp-json/).

Step 2: Execute the Exploit Request
Use the http_request tool to send a GET request to the vulnerable endpoint.

• Request URL: http://<target-ip>:<port>/wp-json/site-prober/v1/logs
• Method: GET
• Headers:
  • Accept: application/json

Step 3: Analyze Response
The expected response is a JSON object containing a logs array.

6. Test Data Setup

To ensure the exploit returns meaningful data, the target environment should have recorded some activity:

1. Install and Activate Plugin: Use wp-cli to install version 1.2.1.
2. Generate Logs:
   • Log in and out of the WordPress admin.
   • Create a dummy post: wp post create --post_title="Audit Target" --post_status=publish.
   • Update a post: wp post update 1 --post_content="Modified content".
   • These actions populate the wpsp_activity table.
3. Verify Table Content (Internal): wp db query "SELECT * FROM wp_wpsp_activity" (to confirm logs exist before testing external exposure).

7. Expected Results

A successful exploit will return a 200 OK response with a body similar to:

{
  "count": 3,
  "logs": [
    {
      "id": "3",
      "created_at": "2023-10-27 10:00:00",
      "user_id": "1",
      "ip": "192.168.1.100",
      "action": "updated",
      "object_type": "post",
      "description": "Post updated: Audit Target"
    },
    {
      "id": "2",
      "created_at": "2023-10-27 09:55:00",
      "user_id": "1",
      "ip": "192.168.1.100",
      "action": "login",
      "object_type": "user",
      "description": "User logged in: admin"
    }
  ]
}

8. Verification Steps

1. Compare JSON Output with Database: Use wp-cli to check the content of the wpsp_activity table and verify it matches the JSON returned by the REST API.

   wp db query "SELECT * FROM wp_wpsp_activity" --list
   

2. Confirm Unauthenticated Access: Verify the http_request was made without any Cookie or Authorization headers.

9. Alternative Approaches

If the standard /wp-json/ prefix is changed by a security plugin, attempt to find the REST API endpoint using the Link header from the homepage:

1. GET /
2. Look for Link: <http://target/wp-json/>; rel="https://api.w.org/".

If the endpoint returns an empty list, ensure the wpsp_activity table is correctly defined. The table name is stored in $wpdb->wpsp_activity. Check its name using:

wp eval "global \$wpdb; echo \$wpdb->wpsp_activity;"

If the table is empty, trigger more actions (e.g., failed login attempts) to populate it.