Exploitation Research Plan: Simple History Unauthenticated Information Exposure (CVE-2026-39473)

1. Vulnerability Summary

The Simple History plugin (up to version 5.24.0) is vulnerable to Unauthenticated Information Exposure. The vulnerability exists because the plugin's REST API endpoint for retrieving activity logs (/wp-json/simple-history/v1/events) fails to implement a proper permission_callback or implements one that incorrectly permits unauthenticated access. This allows any network-level attacker to fetch the entire site activity history, which includes sensitive data like user emails, IP addresses, usernames, and details of configuration changes.

2. Attack Vector Analysis

• Target Endpoint: /wp-json/simple-history/v1/events
• Alternative Endpoint: /wp-json/simple-history/v1/events/<id>/surrounding (introduced in 5.24.0)
• HTTP Method: GET
• Authentication: None (Unauthenticated)
• Preconditions:
  • The plugin must be active.
  • The REST API must be enabled (default in WordPress).
• Parameters:
  • per_page: Number of events to retrieve (e.g., 100).
  • page: Page number for pagination.

3. Code Flow

1. Request Entry: An unauthenticated request is made to GET /wp-json/simple-history/v1/events.
2. REST API Routing: WordPress matches the route to the controller registered by Simple History (likely in inc/class-sh-rest-api-controller.php, though not in the provided snippets).
3. Permission Check: The permission_callback for this route returns true or fails to check for the edit_pages or manage_options capability.
4. Data Retrieval: The controller utilizes the Simple_History\Log_Query class (mentioned in dropins/class-rss-dropin.php) to fetch event data from the database.
5. Information Exposure: The Log_Query results are returned as a JSON response, including the initiator (user details), context (additional event metadata), and message.

4. Nonce Acquisition Strategy

This vulnerability is an Unauthenticated Information Exposure in a REST API GET endpoint. In WordPress, GET requests to the REST API typically do not require a _wpnonce if the permission_callback is set to __return_true or is missing entirely, as nonces are primarily used for CSRF protection in state-changing requests or for session authentication.

Since the goal is unauthenticated exploitation:

• No Nonce Required: The primary exploit assumes the endpoint is public.
• Bypass Verification: If the endpoint returns a 401 Unauthorized or 403 Forbidden with a message suggesting a missing nonce, it indicates that the endpoint might be restricted but improperly configured. However, the CVSS 5.3 rating and the "Unauthenticated" description strongly suggest that no authentication (and thus no nonce) is needed for the vulnerable version.

5. Exploitation Strategy

The goal is to demonstrate that an unauthenticated user can access the activity log.

Step-by-Step Plan:

1. Baseline Check: Confirm the REST API is reachable.
2. Targeted Query: Execute an unauthenticated GET request to the events endpoint.
3. Data Extraction: Parse the JSON response to verify the presence of sensitive data (usernames, emails).

HTTP Request (using http_request tool):

GET /wp-json/simple-history/v1/events?per_page=50 HTTP/1.1
Host: localhost:8080
Accept: application/json

Payloads:

• Basic log retrieval: /wp-json/simple-history/v1/events
• Pagination to find older data: /wp-json/simple-history/v1/events?page=2&per_page=100
• Specific event details: /wp-json/simple-history/v1/events/<id> (if IDs are discovered)

6. Test Data Setup

To confirm the exposure of sensitive data, we must ensure there is sensitive data in the log.

1. Create a Victim User:

   wp user create victim_user victim@example.com --role=author --user_pass=password123
   

2. Perform Administrative Actions:

   wp option update blogname