CVE-2026-85678 in AI Builder Plugin
Summary
by MITRE • 09/11/2026
The AI Builder WordPress plugin before 2.7.8 does not sanitise custom JavaScript saved against a post before echoing it inside a script tag on the front end, allowing users with contributor level access and above to store arbitrary JavaScript that will execute in the browser of anyone who views the post, including the editor or administrator who reviews it.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/11/2026
The vulnerability identified in AI Builder WordPress plugin versions prior to 2.7.8 represents a critical stored cross-site scripting flaw rooted in insufficient input validation and output encoding mechanisms. The core technical deficiency lies in the application's handling of custom JavaScript fields associated with individual posts. When a user submits content containing script tags or executable code, the plugin fails to sanitize this data before persisting it within the database. Subsequently, when the post is rendered on the front end, the unsanitized payload is echoed directly inside a script tag without any form of encoding or escaping. This architectural oversight allows malicious actors with contributor-level access and above to inject arbitrary JavaScript code that becomes part of the page's source structure.
From an operational perspective, this vulnerability enables persistent cross-site scripting attacks against all visitors viewing the affected posts. Unlike reflected XSS which requires tricking a user into clicking a specific link, stored XSS persists on the server side, meaning every subsequent visit to the compromised post triggers the execution of the malicious script in the victim's browser context. This is particularly dangerous because it affects not only general users but also high-privilege accounts such as editors and administrators who routinely review content. If an administrator views a post containing this payload while logged into their administrative session, the injected code executes with elevated privileges within that user's active session, potentially leading to complete compromise of the WordPress installation through cookie theft, session hijacking, or unauthorized administrative actions performed on behalf of the victim.
The security implications align closely with CWE-79, which classifies improper neutralization of input during web page generation as a common cause of cross-site scripting vulnerabilities. Furthermore, this attack vector maps to MITRE ATT&CK technique T1059.007, specifically JavaScript execution within browser environments. The ability for lower-privileged users like contributors to execute code in the context of higher-privileged administrators highlights a significant privilege escalation risk inherent in the plugin's design. This scenario underscores the critical importance of implementing strict allow-listing or robust sanitization routines such as wp_kses_post or similar WordPress-specific functions that strip out dangerous tags and attributes before storage, ensuring that only safe HTML structures are preserved while neutralizing executable script content.
To mitigate this vulnerability, immediate updates to version 2.7.8 or later are required, where the developers have presumably implemented proper sanitization of custom JavaScript fields upon submission. In environments where updating is not immediately feasible, administrators should restrict contributor-level access until patches can be applied and manually audit existing posts for any injected script tags that may have been stored prior to remediation. Additionally, implementing a Content Security Policy header can provide an additional layer of defense by restricting the sources from which scripts are allowed to execute, thereby reducing the impact of successful injection attempts even if input validation fails in future updates.