CVE-2026-111844 in Brizy Plugin
Summary
by MITRE • 10/20/2026
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Brizy Brizy brizy allows Stored XSS.This issue affects Brizy: 2.8.23.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The identified vulnerability represents a classic instance of Improper Neutralization of Input During Web Page Generation, commonly known as Cross-Site Scripting or XSS. Specifically, this flaw manifests as a Stored XSS within the Brizy page builder ecosystem for WordPress, affecting version 2.8.23 and potentially earlier iterations depending on deployment configurations. Unlike reflected XSS where malicious scripts are executed via manipulated URLs, stored XSS involves the persistence of malicious input on the target server. In the context of Brizy, this implies that an attacker can inject executable JavaScript code into content fields or settings within the page builder interface. Because Brizy is a visual drag-and-drop editor used extensively for creating and managing website layouts, any data entered through its administrative interface is often rendered directly to end-users visiting those pages without sufficient sanitization checks.
The technical root cause lies in the insufficient validation and encoding of user-supplied input before it is processed by the application's rendering engine. When a privileged user or an attacker with access to the Brizy editor inputs malicious script payloads, such as event handlers like onerror or onload attributes attached to HTML tags, these scripts are saved into the database associated with that specific page or widget configuration. Subsequently, when any visitor loads the affected webpage, their browser parses the stored content and executes the embedded JavaScript in the context of the victim's session. This mechanism bypasses same-origin policy protections because the malicious script originates from a trusted domain—the legitimate website itself—making it particularly dangerous as browsers will not block execution based on origin alone.
The operational impact of this vulnerability is severe due to its persistent nature and potential for widespread exploitation. Once the payload is stored, every user who views the compromised page becomes a potential victim without requiring any further interaction from the attacker beyond initial injection. This allows for significant consequences including session hijacking, where attackers can steal authentication cookies or tokens to impersonate legitimate users. It also facilitates credential harvesting through fake login forms injected into the page content, defacement of the website by altering displayed text or images, and redirection of traffic to malicious sites hosting malware or phishing campaigns. Furthermore, if the compromised account has administrative privileges, an attacker could use this access to install additional backdoors, modify site settings, or escalate their privilege level within the WordPress environment, effectively taking full control of the web application infrastructure.
From a classification perspective, this vulnerability aligns with CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'). The specific behavior maps to ATT&CK technique T1059.007: JavaScript under Command and Control or Execution frameworks, where attackers leverage browser-based scripting languages to execute arbitrary code on client systems. It also relates to CWE-834: Excessive Iterative Restriction which may be present if input filtering rules are too narrow and easily bypassed using encoding tricks or alternative event handlers that were not explicitly blocked by the application's security controls.
Mitigation strategies must address both immediate remediation and long-term defensive posture improvements. The primary corrective action is to upgrade Brizy to a version later than 2.8.23 where this specific input validation flaw has been patched by the developers. Until an update can be applied, administrators should restrict access to the page builder interface strictly to trusted users with verified identities and strong multi-factor authentication enabled. Implementing a Web Application Firewall (WAF) configured with rulesets specifically tuned for XSS detection can provide a layer of defense by blocking requests containing known malicious script patterns before they reach the application logic. Additionally, developers should enforce strict output encoding using context-aware methods such as HTML entity encoding for data rendered in HTML bodies and JavaScript string escaping for dynamic content insertion into scripts. Content Security Policy (CSP) headers should also be deployed to restrict the sources from which scripts can be loaded or executed, thereby mitigating the impact even if an injection attempt succeeds by preventing unauthorized script execution.