CVE-2026-15101 in WPBakery Page Builder Plugin
Summary
by MITRE • 09/01/2026
The WPBakery Page Builder plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'data' parameter in all versions up to, and including, 8.7.4 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with subscriber-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. The wp_kses_post sanitization applied during save does not neutralize the payload because the malicious script content is base64-encoded as plain alphanumeric text with no HTML tags to strip; the vc_raw_html shortcode template then decodes and echoes this content unescaped at render time.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The WPBakery Page Builder plugin, a widely utilized tool for creating dynamic layouts in WordPress environments, contains a critical security flaw identified as Stored Cross-Site Scripting within its data handling mechanisms. This vulnerability persists across all versions up to and including 8.7.4, stemming from insufficient input sanitization and output escaping practices during the content processing lifecycle. The core of the issue lies in how the plugin processes user-supplied data through specific parameters, allowing malicious actors to inject executable scripts that persist within the database until explicitly removed by an administrator or developer.
The technical flaw is rooted in a flawed security assumption regarding input validation. When a page is saved, the application applies wp_kses_post sanitization, which is designed to strip out dangerous HTML tags and attributes such as script elements or event handlers like onerror. However, attackers bypass this defense mechanism by encoding their malicious payloads using base64 encoding. Because the encoded string consists of plain alphanumeric characters without any recognizable HTML tag structures, the sanitizer fails to identify it as a threat and allows it to pass through into the database storage layer intact. This evasion technique effectively neutralizes the protective measures intended to filter out harmful content during the input phase.
The exploitation vector requires authenticated access with at least subscriber-level privileges, which significantly lowers the barrier for entry compared to unauthenticated attacks but still represents a serious risk in multi-user WordPress installations where user roles may not be strictly audited or limited. Once an attacker successfully injects the base64-encoded payload via the vulnerable data parameter, it is stored within the post content associated with the specific page being edited. The actual execution of the malicious code occurs at render time rather than during input submission. When a visitor accesses the compromised page, the plugin processes the vc_raw_html shortcode template present in the saved content. This template decodes the base64 string and echoes the resulting script directly into the HTML output without applying any additional escaping or sanitization checks. Consequently, the browser interprets and executes the injected JavaScript within the context of the victim's session.
The operational impact of this vulnerability is severe due to its stored nature. Unlike reflected XSS attacks that require tricking a user into clicking a malicious link, stored XSS ensures that every visitor who views the affected page becomes a potential target for exploitation. Attackers can leverage this capability to steal administrative credentials through cookie theft, hijack active sessions, perform actions on behalf of legitimate users such as creating new posts or modifying site settings, and even deploy further malware by redirecting visitors to phishing sites or exploit kits. The persistence of the payload means that the threat remains active until manual intervention occurs, potentially affecting a large number of users over an extended period if left undetected.
From a classification perspective, this vulnerability aligns with CWE-79 Improper Neutralization of Input During Web Page Generation commonly known as Cross-site Scripting and specifically falls under Stored XSS variants where the payload is persisted in data stores. In terms of attack lifecycle mapping according to MITRE ATT&CK for Enterprise or Software, this behavior corresponds to T1059 Command and Scripting Interpreter through JavaScript execution within a browser environment, facilitating subsequent tactics such as Credential Access via Browser Session Hijacking (T1539) or Collection if data exfiltration scripts are deployed.
Mitigation strategies must address both immediate remediation and long-term security hygiene. The primary defense is to upgrade the WPBakery Page Builder plugin to a version newer than 8.7.4 where this specific input validation flaw has been patched by applying proper escaping at output time regardless of input encoding methods. For organizations unable to update immediately, implementing Web Application Firewall rules that detect and block base64-encoded script injections in post content fields can provide temporary protection. Additionally, enforcing strict role-based access control ensures that only trusted administrators with verified identities have the ability to edit page content, thereby reducing the attack surface available to lower-privileged users who might otherwise exploit this flaw. Regular security audits focusing on output encoding practices for all dynamic content rendered by plugins are essential to prevent similar vulnerabilities in future updates or other third-party extensions.