skrkcb2/cve-2025-0924-differentTechnical analysis of CVE-2025-0924, a Stored XSS vulnerability in WP Activity Log plugin for WordPress. Includes root cause analysis, exploitation demonstration, and remediation guidance.
Stored XSS is a type of vulnerability where a malicious script is stored on the server and later automatically executed when other users open the page, designated as CWE-79 (Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')).
WordPress is the most popular open-source CMS (Content Management System) worldwide, enabling users to easily build and manage websites and blogs. Users can extend and customize their sites through various plugins and themes without requiring coding knowledge.
WP Activity Log is a plugin that tracks and records administrative activities on WordPress sites. It helps administrators monitor various events occurring on the site in real time and provides logs for security audits and troubleshooting.
CVE-2025-0924 affects the WP Activity Log plugin (versions 5.2.2 and below) and is caused by insufficient input validation and inadequate output escaping in the 'message' parameter. We will examine how this vulnerability occurs and explore countermeasures.
In WordPress, if a user copies and pastes a malicious script into the site title and the change is logged by WP Activity Log 5.2.2, a Stored XSS attack occurs. Through an example, we will examine how WP Activity Log leads to Stored XSS.
[Figure 1] WordPress Post Creation, DB Script Injection
Looking at [Figure 1], first, we create a post to generate logs. In this process, we write two posts: one by directly typing and the other by copying and pasting.After creating the posts, checking the database reveals that for the copied and pasted post, the post_title field value is stored without being properly sanitize (input cleaning and filtering).
This suggests that data may be processed differently depending on the input method, and it can be a cause for an XSS (Cross-Site Scripting) vulnerability.
[Figure 2] WP Activity Log Log Creation and Attack Check
The posts created in [Figure 1] remain as logs in WP Activity Log. While fetching information from the database and requesting 'More details...', we can confirm the script execution in [Figure 2]. 
[Figure 3] class-list-events.php - More details... return
As seen in [Figure 3], 'More details...' receives AjaxInspector (ajax callback function / get metadata) and occurrence, then outputs the result. 
[Figure 4] AuditLog.php -> AjaxInspector() - non sanitize
[Figure 4] metadata sample
AjaxInspector, seen in [Figure 3] from [Figure 4], returns variables without sanitizing them while generating results through [Figure 5] metadata, causing the vulnerability to occur.So far, we have examined Stored XSS through WP Activity Log, a WordPress security log plugin. This vulnerability can occur if a user can create pages or upload script content into logs. As a countermeasure, we recommend updating WP Activity Log from version 5.2.2 and below to version 5.3.0.
[Figure 5] AjaxInspector changes / addition of esc_html()
In this case, it appears that the problem occurred because esc_html() was not used to properly sanitize the returned HTML. However, I am not yet confident whether this analysis exactly matches the vulnerability described in CVE-2025-0924.
I have tested after upgrading to version 5.3.0 and confirmed that the measure has been applied. However, the vulnerability described in CVE-2025-0924 is through the Stored Cross-Site Script via the ##message## parameter, and it specifies class-alert.php and class-alert-manager.php as the path, but
In my analysis, the problem lies in the meta data, not the message parameter, and the PHP files involved in the process are class-list-events.php and AuditLog.php. Therefore, except for Stored Cross-Site Script, nothing matches the NIST description. Hence, further investigation is needed to determine exact correspondence.
