CVE-2026-92712 in ReactPress Plugin
Summary
by MITRE • 09/30/2026
The ReactPress – Create React App for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'permalink' parameter in all versions up to, and including, 3.4.0 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. This is possible because the permalink parameter is only passed through sanitize_url(), which does not prevent fetching attacker-controlled remote URLs whose response body — including script tags and event-handler attributes — is written verbatim to disk via file_put_contents().
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/30/2026
The ReactPress plugin, designed to integrate Create React App workflows into WordPress environments, contains a critical security flaw in versions up to 3.4.0 that allows for stored cross-site scripting attacks. This vulnerability stems from insufficient input sanitization and output escaping mechanisms within the application's handling of user-supplied data. Specifically, the issue resides in the processing of the permalink parameter, which is intended to store valid web addresses but fails to adequately validate or sanitize inputs before persistence. The flaw enables authenticated attackers with subscriber-level access or higher privileges to inject malicious JavaScript code into stored content, thereby compromising the integrity and security of the WordPress installation and its users.
The technical root cause lies in the specific function used for input validation, namely sanitize_url(). While this function performs basic structural checks on URLs, it does not prevent the use of remote URLs that return hostile payloads. When an attacker provides a permalink pointing to a malicious server controlled by them, the plugin accepts this value and proceeds to write the response body directly to disk using file_put_contents() without further inspection or escaping. Consequently, if the remote URL returns HTML content containing script tags or event-handler attributes, these elements are saved verbatim into the local files associated with the post or page metadata. This mechanism effectively bypasses standard WordPress security measures that typically rely on client-side filtering and server-side output escaping to prevent code execution in browser contexts.
The operational impact of this vulnerability is significant due to its stored nature. Unlike reflected cross-site scripting, where malicious scripts are executed only when a victim clicks a specially crafted link, the payload here persists within the application's database or file system. Whenever an administrator, editor, or any other user with sufficient permissions views the affected page in their web browser, the injected script executes automatically. This allows attackers to perform actions such as stealing session cookies, hijacking administrative sessions, defacing websites, or redirecting users to phishing sites. The requirement for subscriber-level access lowers the barrier to entry for exploitation, making it feasible for lower-privileged accounts within a WordPress installation to compromise higher-privilege workflows and sensitive data.
From an industry standards perspective, this vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation as cross-site scripting. The attack vector also maps to MITRE ATT&CK techniques related to client-side injection and persistence through stored payloads. To mitigate this risk, immediate updates to version 3.4.1 or later are recommended, where the developers have likely implemented stricter validation rules for the permalink parameter. In addition to updating, administrators should enforce strict input sanitization practices that go beyond basic URL structure checks, ensuring that only expected local paths or verified external domains are accepted. Furthermore, implementing Content Security Policy headers can help mitigate the impact of any remaining script injection attempts by restricting the sources from which scripts can be loaded and executed within the browser environment.