Description

The Brizy – Page Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'brizy-compiled-sections' parameter in all versions up to, and including, 2.8.18 due to insufficient input sanitization and output escaping. 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-10-10T06:16:41.900Z",
  "pubdate": "2026-10-10T06:16:41.900Z",
  "executiveSummary": "The Brizy – Page Builder plugin for WordPress is susceptible to a Stored Cross-Site Scripting (XSS) vulnerability. This security flaw exists in versions up to and including 2.8.18 due to the improper sanitization of user-supplied data within the 'brizy-compiled-sections' parameter.\nThe vulnerability allows authenticated attackers with at least contributor-level privileges to inject malicious JavaScript into WordPress pages. When a victim, such as an administrator or another site user, views the compromised page, the embedded script executes within their browser session.\nThe impact of this vulnerability is significant, as it enables unauthorized script execution in the context of the user's session. This may lead to session hijacking, unauthorized actions performed on behalf of the user, redirection to malicious websites, or the exfiltration of sensitive information.\nExploitation requires the attacker to possess an authenticated account with contributor-level permissions or higher. While this restricts the initial attack vector, the elevated privileges required for a contributor in WordPress environments mean that the threat is particularly relevant in multi-user environments where untrusted individuals are granted site access.\nOrganizations using Brizy should prioritize identifying if they are within the affected version range and implement necessary updates to mitigate potential exploitation attempts.",
  "technicalDetails": "The root cause of this vulnerability is the inadequate sanitization and output escaping of input provided via the 'brizy-compiled-sections' parameter. In the context of web application security, Stored XSS occurs when an application receives data from an untrusted source and includes that data within its later HTTP responses in an unsafe way.\nIn the Brizy Page Builder plugin, the application accepts input for compiled page sections without performing rigorous server-side validation or contextual output encoding. Consequently, malicious payloads—such as JavaScript event handlers or `<script>` tags—are stored directly within the database. When the affected page is subsequently rendered, the server transmits the unsanitized payload to the client's browser, which processes it as executable code rather than plain text.\nThe attack flow proceeds as follows: First, an attacker with contributor-level access logs into the WordPress dashboard. Second, the attacker interacts with the Brizy page builder interface to modify a page, injecting a malicious JavaScript payload into the 'brizy-compiled-sections' parameter. Third, the plugin saves this malicious content to the database without stripping the script elements. Fourth, when a legitimate user (such as an editor or administrator) navigates to the modified page, the WordPress instance serves the stored payload. Finally, the victim's browser interprets the malicious script, executing it with the privileges of the victim's session.\nThis vulnerability is classified as Stored (or Persistent) XSS because the malicious script resides permanently on the target server's database. Unlike Reflected XSS, which requires the victim to click a specially crafted link, Stored XSS automatically triggers the payload whenever a user visits the compromised page, significantly increasing the potential for successful exploitation and impact.\nThe exploitation of this flaw can have severe post-exploitation consequences. Because the injected code executes in the context of the victim's browser session, the attacker can perform actions that the user is authorized to perform, such as modifying other pages, creating new administrative accounts, or accessing sensitive dashboard settings. Furthermore, an attacker may use this execution capability to steal session cookies or credentials, effectively leading to a complete compromise of the victim's WordPress session or potentially escalating to broader administrative control over the entire WordPress installation."
}