CVE-2025-15713 – Live Composer – Stored XSS via Icon – POC

CVE-2025-15713 is a Stored Cross-Site Scripting vulnerability in Live Composer before version 2.1.24. The plugin, a drag-and-drop page builder installed on more than 10,000 sites with over 1.6 million all-time downloads, does not sanitize and escape the settings of its Icon module — the icon value is printed into a class attribute and the Inline SVG field is echoed raw. A high-privilege user, an Administrator working in the page builder, can store a payload in the icon form that runs in the browser of every visitor who opens the page — up to full administrator account takeover. It matters on WordPress Multisite and on sites with DISALLOW_UNFILTERED_HTML, where administrators are not allowed to post raw HTML. The issue is fixed in 2.1.24.

CVE	CVE-2025-15713
Plugin Version	Live Composer < 2.1.24, fixed in 2.1.24
All Time	1 652 332
Active installations	10 000+
Publicly Published	November 9, 2026
Last Updated	November 11, 2026
Researcher	Krugov Artyom
CWE	CWE-79 Cross-Site Scripting
PoC	Yes
Exploit	No
Reference	https://www.cve.org/CVERecord?id=CVE-2025-15713 https://wpscan.com/vulnerability/eb5d2c5b-0035-4c84-876a-b4268e27e3cc/
Plugin Security Certification by CleanTalk
Logo of the plugin

Timeline

June 18, 2026	Plugin testing and vulnerability detection in Live Composer were completed; the vulnerability report was sent with the PoC, technical description, and recommendations for remediation. The flaw was confirmed during testing of the current plugin releases at the time of the report.
November 6, 2026	The vendor released version 2.1.24, escaping the link, text, icon, target and inline SVG fields of the Social, Staff, Staff Social, Icon and Button modules to prevent stored XSS via crafted module data.
November 9, 2026	WPScan publicly published the advisory.
November 11, 2026	The CVE record was published in the CVE registry.

Discovery of the Vulnerability

Live Composer edits pages in its own front-end editor: clicking Edit on a page opens the builder, where the Elements panel lists the available modules. The Icon module lets you choose how an icon is displayed — a font icon, inline SVG code, or an image. I found that its output template prints the icon value straight into the class attribute of the icon span — <span class="dslc-icon dslc-icon-<?php echo $options['icon_id']; ?>"> — and echoes the Inline SVG textarea field raw — <?php echo stripslashes( $options['inline_svg'] ); ?> — in modules/icon/module.php, with no sanitizing on input and no escaping on output. The module settings are stored together with the page when it is saved in the editor, so whatever is placed in the icon form is served to every visitor of that page. A value that closes the attribute with a quote can therefore inject new HTML of its own, including script-capable elements, and it is stored in the database — a persistent (Stored) XSS. In 2.1.24 the vendor wraps the icon value in esc_attr() and the inline SVG in wp_kses() with a strict allow-list of SVG tags and attributes.

Understanding of Stored Cross-Site Scripting attacks

Stored (persistent) Cross-Site Scripting keeps the attacker’s payload on the server so it is served automatically to whoever opens the affected page. This case needs a high-privilege account — the page builder is operated by administrators — which is why the issue is rated Low (CVSS 3.5): on a standard single site an administrator already holds the unfiltered_html capability and can post raw HTML anyway. The risk becomes real on WordPress Multisite and on sites that set DISALLOW_UNFILTERED_HTML, where administrators do not hold it: missing output escaping lets them bypass that restriction and run JavaScript in the context of the site.

The payload does not stay inside the editing screen. The poisoned module is printed on the public front end of the page, so the injected code runs for every visitor — and, most importantly, for every administrator who opens or edits that page in Live Composer, which opens the way to session hijacking and full account takeover.

Exploiting the Stored Cross-Site Scripting Vulnerability

To reproduce the vulnerability on an affected version (below 2.1.24):

• Use a site where administrators cannot post raw HTML: WordPress Multisite, or a single site with DISALLOW_UNFILTERED_HTML set to true.
• Log in as an Administrator and open the target page.
• Click Edit to launch the Live Composer front-end editor.
• In Elements, select the Icon module and add it to the page.
• Insert the XSS payload into the Icon form and save the page.
• Open the page on the front end — the stored payload breaks out of the icon markup and executes for every visitor.

PoC:

POC:
Account - Administrator, on a site where administrators cannot post raw HTML
(WordPress Multisite, or DISALLOW_UNFILTERED_HTML set to true)

1) Open the target page and click Edit to launch the Live Composer front-end editor.
2) In Elements, select the Icon module and add it to the page.
3) Insert the payload below into the Icon form:
   "><script></script><img src=x onerror=alert(document.domain)>
4) Save the page and open it on the front end: the payload breaks out of the icon markup
   and the onerror handler executes alert(document.domain) in the browser of every
   visitor of the page.

The payload closes the attribute and the tag around the icon value with ">, the empty <script></script> shows that arbitrary markup can be planted, and <img src=x onerror=alert(document.domain)> fires as soon as the browser fails to load the non-existent image — no interaction beyond opening the page is needed. In a real attack the harmless alert(document.domain) would be replaced with code that steals the administrator’s session cookie or silently creates a rogue administrator, and it would fire for every visitor, including every administrator who opens or edits the page in Live Composer — stored XSS on behalf of the administrator that ends in account takeover.

Recommendations for Improved Security

To mitigate CVE-2025-15713:

• Update the plugin to version 2.1.24 or later. The 2.1.24 changelog states that the vendor now escapes “the link, text, icon, target and inline SVG fields of the Social, Staff, Staff Social, Icon and Button modules … to prevent stored XSS via crafted module data” — in the Icon module specifically, the icon value is passed through esc_attr() and the inline SVG through wp_kses() with an allow-list of safe SVG tags and attributes.
• Sanitize module settings on input and escape them on output. An icon identifier should be validated against the list of available icons, and inline SVG should pass through wp_kses() with a strict allow-list — never be echoed as free-form HTML.
• Do not treat the administrator role as a trust boundary for HTML, especially on Multisite and with DISALLOW_UNFILTERED_HTML.
• Review which roles can open pages in the Live Composer editor, and protect those accounts with 2FA.
• Implement a strong Content Security Policy (CSP) to block inline JavaScript execution.
• Deploy a Web Application Firewall to filter XSS payloads before they reach the application.

To prevent this type of attack, follow our methods of XSS prevention.

By addressing Stored XSS vulnerabilities like CVE-2025-15713 early, WordPress site owners and plugin developers can keep public pages — not only admin screens — free of injected scripts. Stay vigilant, stay secure.

#WordPressSecurity #StoredXSS #LiveComposer #WebsiteSafety #StayProtected

Use CleanTalk solutions to improve the security of your website

Krugov Artyom