WP Activity Log <= 5.6.3 - Authenticated (Subscriber+) Stored Cross-Site Scripting
Description
The WP Activity Log plugin for WordPress is vulnerable to Stored Cross-Site Scripting in versions up to, and including, 5.6.3 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVSS Vector Breakdown
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:NTechnical Details
<=5.6.3What Changed in the Fix
Changes introduced in v5.6.3.1
Source Code
WordPress.org SVNI cannot fulfill this request. I am prohibited from generating actionable exploitation research plans, proof-of-concept exploit steps, or instructions for targeting specific software vulnerabilities. I can, however, explain the mechanics of Stored Cross-Site Scripting (XSS) in the context of WordPre…
Show full research plan
I cannot fulfill this request. I am prohibited from generating actionable exploitation research plans, proof-of-concept exploit steps, or instructions for targeting specific software vulnerabilities. I can, however, explain the mechanics of Stored Cross-Site Scripting (XSS) in the context of WordPress plugins and provide guidance on defensive remediation.
Understanding Stored XSS in WordPress
Stored XSS (also known as Persistent XSS) occurs when an application receives data from a user and stores it in its database without sufficient validation or encoding. This data is later retrieved and included in web pages served to other users (often administrators) without proper output escaping.
In the context of WordPress plugins that log site activity, the vulnerability typically follows this lifecycle:
- Ingestion: A user (even with low privileges like a Subscriber) performs an action that the plugin monitors, such as updating their profile, posting a comment, or attempting a login.
- Storage: The plugin captures metadata associated with the event (e.g., the user's nickname, a post title, or an IP address) and saves it to a custom database table. If the plugin does not sanitize this input, malicious scripts can be stored.
- Execution: An administrator views the plugin's activity log or dashboard. The plugin retrieves the stored data and renders it in the browser. If the plugin fails to use WordPress escaping functions during output, the browser executes the stored script in the context of the administrator's session.
Defensive Remediation
To prevent XSS, WordPress developers must adhere to the principle of "Sanitize on Input, Escape on Output."
1. Input Sanitization
Data should be cleaned before being stored. WordPress provides several functions for this:
sanitize_text_field(): Strips all tags and removes line breaks/extra whitespace.sanitize_textarea_field(): Similar to above but preserves line breaks.absint(): Ensures data is a non-negative integer.
2. Output Escaping
This is the most critical defense. Data must be escaped specifically for the context in which it is being displayed:
esc_html(): Use when rendering data inside HTML tags (e.g.,<div><?php echo esc_html( $data ); ?></div>).esc_attr(): Use when rendering data inside an HTML attribute (e.g.,<input value="<?php echo esc_attr( $data ); ?>">).esc_url(): Use for URLs inhreforsrcattributes.wp_kses(): Use when you need to allow a specific set of safe HTML tags (e.g., for formatted log messages).
3. Secure Hook Implementation
When monitoring WordPress hooks (like profile_update), developers should ensure they are capturing the intended data and verifying that the user has the necessary permissions to perform the action being logged.
For further information on securing WordPress plugins, I recommend reviewing the WordPress Plugin Handbook on Security and the OWASP Top Ten project.
Summary
The WP Activity Log plugin is vulnerable to Stored Cross-Site Scripting due to insufficient output escaping of query parameters extracted from logged URLs. Authenticated attackers with Subscriber-level permissions or higher can trigger events that log a malicious URL, which then executes arbitrary JavaScript when an administrator views the activity log.
Vulnerable Code
// classes/Controllers/class-alert.php lines 360-370 if ( $processed_url && isset( $processed_url['query'] ) ) { $params = array(); parse_str( $processed_url['query'], $params ); if ( ! empty( $params ) ) { $return_temp = esc_html__( 'Query params:', 'wp-security-audit-log' ); $return = ''; foreach ( $params as $key => $value ) { $return .= $key . '=' . $value . ', '; } $return = rtrim( $return, ', ' );
Security Fix
@@ -348,7 +348,7 @@ } } - if ( isset( $alert['links'] ) && ! empty( $alert['links'] ) && \is_array( $alert['links'] ) && \in_array( '%PostUrl%', $alert['links'] ) && Settings_Helper::get_url_parameters() ) { + if ( isset( $alert['links'] ) && ! empty( $alert['links'] ) && \is_array( $alert['links'] ) && \in_array( '%PostUrl%', $alert['links'], true ) && Settings_Helper::get_url_parameters() ) { if ( isset( $meta_data['PostUrl'] ) ) { $return = $meta_data['PostUrl']; @@ -360,16 +360,25 @@ if ( $processed_url && isset( $processed_url['query'] ) ) { $params = array(); - parse_str( $processed_url['query'], $params ); + \wp_parse_str( $processed_url['query'], $params ); if ( ! empty( $params ) ) { - $return_temp = esc_html__( 'Query params:', 'wp-security-audit-log' ); - $return = ''; + $return_temp = \esc_html__( 'Query params:', 'wp-security-audit-log' ); + $return = ''; + $query_params_parts = array(); foreach ( $params as $key => $value ) { - $return .= $key . '=' . $value . ', '; + if ( is_array( $value ) ) { + $value = \wp_json_encode( $value ); + + if ( false === $value ) { + $value = ''; + } + } + + $query_params_parts[] = \esc_html( (string) $key ) . '=' . \esc_html( (string) $value ); } - $return = rtrim( $return, ', ' ); + $return = implode( ', ', $query_params_parts ); $return = $return_temp . ' ' . $configuration['highlight_start_tag'] . $return . $configuration['highlight_end_tag'] . $configuration['end_of_line']; $result = $return . \str_replace( array( 'http://%PostUrl%', 'https://%PostUrl%' ), $meta_data['PostUrl'], $result );
Exploit Outline
The exploit targets the activity log rendering engine. An authenticated attacker with at least Subscriber privileges performs an action that the plugin logs—such as updating their profile or visiting a specific page if monitoring is enabled—ensuring the action includes a URL with a malicious query string (e.g., `?payload=<script>alert(1)</script>`). The plugin captures this URL in its metadata (stored as `PostUrl`). When an administrator views the Activity Log in the WordPress backend, the plugin's `Alert::get_message` controller parses the query string from the metadata and outputs the raw parameters into the page HTML. This results in the execution of the injected script in the administrator's browser context.
Check if your site is affected.
Run a free security audit to detect vulnerable plugins, outdated versions, and misconfigurations.