CVE-2025-15708 is a Stored Cross-Site Scripting vulnerability in Live Composer before version 2.1.23. 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 its module link settings — such as the social network fields of the Social module — before using them in front-end links. A high-privilege user, an Administrator working in the page builder, can store a payload in a module form that breaks out of the link attributes rendered by the builder, so it 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.23, and the current release 2.1.24 additionally escapes the Social module fields used in the PoC below.
| CVE | CVE-2025-15708 |
| Plugin Version | Live Composer < 2.1.23, fixed in 2.1.23 (the Social module link fields from the PoC are additionally escaped in 2.1.24) |
| All Time | 1 652 332 |
| Active installations | 10 000+ |
| Publicly Published | November 5, 2026 |
| Last Updated | November 7, 2026 |
| Researcher | Krugov Artyom |
| CWE | CWE-79 Cross-Site Scripting |
| PoC | Yes |
| Exploit | No |
| Reference | https://www.cve.org/CVERecord?id=CVE-2025-15708 https://wpscan.com/vulnerability/44369f11-99b5-4745-8e6b-aa705c3f8ce5/ |
| Plugin Security Certification by CleanTalk |  |
| Logo of the plugin |  |
Join the community of developers who prioritize security. Highlight your plugin in the WordPress catalog.
PSC by Cleantalk
Timeline
| Not recorded | Plugin testing and vulnerability detection in Live Composer were completed; the vulnerability report was sent with the PoC, technical description, and recommendations for remediation. |
| November 4, 2026 | The vendor released version 2.1.23, the version listed as containing the fix: slug settings are sanitized and listing module permalinks are escaped. |
| November 5, 2026 | WPScan publicly published the advisory for CVE-2025-15708. |
| November 6, 2026 | The vendor released version 2.1.24, additionally escaping the link fields of the Social, Staff, Staff Social, Icon and Button modules — the vector demonstrated in the PoC. |
| November 7, 2026 | The CVE-2025-15708 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. I found that the Social module takes a URL for each network — Facebook, Twitter, YouTube and more — and its output template prints these values straight into link attributes: <a class="dslc-social-icon" … href="<?php echo $options[$id]; ?>"> in modules/social/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 fields 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. The same missing-escaping pattern also affected the plugin’s custom post type slug settings and the listing module permalinks, which the vendor addressed in 2.1.23 and the CVE record covers.
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 social link 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:
- Use a site where administrators cannot post raw HTML: WordPress Multisite, or a single site with
DISALLOW_UNFILTERED_HTMLset totrue. - Log in as an Administrator and open the target page.
- Click Edit to launch the Live Composer front-end editor.
- In Elements, select the Social module and add it to the page.
- Insert the XSS payload into one of the social media form fields — Facebook, Twitter or YouTube — and save the page.
- Open the page on the front end — the stored payload breaks out of the link attribute 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 Social module and add it to the page.
3) Insert the payload below into one of the social media form fields -
Facebook, Twitter or YouTube:
"><script></script><img src=x onerror=alert(document.domain)>
4) Save the page and open it on the front end: the payload closes the href attribute,
and the onerror handler executes alert(document.domain) in the browser of every
visitor of the page.The payload closes the href attribute and the link tag 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-15708:
- Update the plugin to the latest version — 2.1.23 sanitizes the slug settings and escapes the listing module permalinks, and 2.1.24 additionally escapes the link, text, icon, target and inline SVG fields of the Social, Staff, Staff Social, Icon and Button modules with
esc_url()/esc_html(), which closes the vector used in the PoC. - Sanitize module settings on input and escape them on output with
esc_url()for URLs andesc_attr()for attributes — a URL field is a URL, never 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-15708 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
