Description

The Live Composer – Free WordPress Website Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'custom_id' shortcode attribute of the dslc_modules_section and dslc_modules_area shortcodes in versions up to, and including, 2.1.19. This is due to insufficient input sanitization and output escaping on the user-supplied attribute, which is concatenated into the HTML id="" attribute of the rendered <div> element in the dslc_modules_section_front() and dslc_modules_area_front() functions without esc_attr(). This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.4",
  "pubDate": "2026-09-01T05:17:08.713Z",
  "pubdate": "2026-09-01T05:17:08.713Z",
  "executiveSummary": "The Live Composer – Free WordPress Website Builder plugin, in versions up to and including 2.1.19, is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability. This flaw arises from improper handling of user-supplied input within specific shortcode attributes.\nThe vulnerability allows authenticated attackers with Contributor-level access or higher to inject malicious JavaScript into the WordPress environment. When a victim views a page containing the compromised shortcode, the injected script executes within the context of the user's browser session.\nThe impact is significant, potentially leading to unauthorized actions performed on behalf of the victim, session hijacking, or the redirection of users to malicious third-party domains. Since the injected payload is stored within the database, the execution is persistent until the payload is removed. The risk is elevated by the low privilege requirement of 'Contributor', which is often granted to untrusted users in collaborative WordPress environments. Organizations utilizing this plugin should prioritize updating to a version that addresses this sanitization defect or apply immediate compensatory controls to restrict access to the affected shortcodes.",
  "technicalDetails": "The root cause of this vulnerability is the lack of server-side input sanitization and output escaping for the 'custom_id' attribute within the 'dslc_modules_section' and 'dslc_modules_area' shortcodes. These shortcodes process user-defined settings to render HTML layouts, specifically targeting the id attribute of div elements generated by the functions dslc_modules_section_front() and dslc_modules_area_front().\nIn the vulnerable code, the 'custom_id' value is retrieved from the shortcode attributes and directly concatenated into the HTML structure of the output div element without being passed through the esc_attr() function. This failure to neutralize special HTML characters—such as double quotes, angular brackets, and event handler attributes—allows an attacker to break out of the intended id=\"\" attribute container.\nAn attacker can exploit this by crafting a malicious shortcode payload: [dslc_modules_section custom_id='\" onmouseover=\"alert(document.cookie)\"']. When the plugin renders this shortcode, the resulting HTML becomes <div id=\"\" onmouseover=\"alert(document.cookie)\" ...>. Because the plugin fails to sanitize the input or escape the output, the browser interprets the injected onmouseover event as legitimate markup.\nThe attack flow proceeds as follows: First, an authenticated attacker with Contributor privileges crafts a post or page containing the malicious shortcode. Second, the WordPress server saves this input into the wp_posts database table without performing security validation on the 'custom_id' parameter. Third, when an administrator or any other authenticated user views the frontend page where the module is rendered, the server-side function dslc_modules_section_front() or dslc_modules_area_front() injects the unsanitized payload into the DOM.\nFinally, the victim's browser parses the malicious HTML, executing the arbitrary JavaScript within the security context of the victim's session. Post-exploitation impact includes the potential for session token theft via cookie access, unauthorized administrative actions such as creating new administrative accounts, or modifying plugin and theme configurations. Because this occurs via a stored mechanism, the exploit is persistent, meaning every subsequent visit to the page triggers the malicious script execution, significantly increasing the probability of successful compromise."
}