WordPress 7.1.4 fixes 22 flaws, including update RCE
WordPress 7.1.4 was released on 28 October 2026 with fixes for 22 vulnerabilities covered by 17 security advisories. The preceding 7.1.3 release had addressed seven flaws three weeks earlier. Most of the newly fixed issues require an existing account, usually with Contributor access or higher, but one race condition could lead to remote code execution without authentication. A race condition is a flaw that depends on actions occurring in a narrow and unintended sequence, while remote code execution, or RCE, means making a server run attacker-controlled code.
WordPress issued backports, which are fixes adapted for older software branches, on the same day for every supported branch through 4.7.39. Available releases include 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 and 6.4.14, with further backports down to 4.7.39. Sites running WordPress 4.6 or older receive no update. WordPress 7.1.4 is available through Dashboard, Updates and WordPress.org, while sites with background updates enabled should install it automatically.
Patchstack’s code analysis found that the most consequential flaw was in the core upgrade process. During an installation or update, WordPress extracts a package into wp-content/upgrade/, a directory that may be served publicly by the web server. Before 7.1.4, the extracted folder inherited the package name, making its location predictable for packages uploaded through the administration area. The initial cleanup also removed everything in the upgrade directory, including the index.php file that prevents visitors from seeing a directory listing.
For the few seconds needed to complete an update, the extracted files could therefore form a complete WordPress installation at a guessable, potentially browsable address. That copy included wp-admin/setup-config.php, which could start independently without the live site’s configuration. An attacker reaching it during the update window could run the installer against a database under the attacker’s control while remaining inside the victim site’s document root, the web-accessible folder containing the site. No account or user interaction was required, although the timing and exposure requirements made exploitation difficult.
WordPress 7.1.4 adds 16 random characters to the temporary folder name, restores index.php and no longer deletes that file. Patchstack also identified a separate update-core.php change that prevents wp-config.php from being copied out of the working directory. Patchstack rated the flaw AC:H, meaning high attack complexity, and said it was not practical to exploit. Even so, the vulnerable mechanism dated back to WordPress 2.8 and reappeared during every update, including unattended updates.
A firewall implemented in PHP, the programming language in which WordPress runs, cannot intercept this particular request. Patchstack explains that the extracted copy loads its own WordPress files, while the official archive contains no mu-plugins directory for automatically loaded plugins, so the live site’s PHP firewall never starts. The recommended server-level mitigation is to deny web access to wp-content/upgrade/ and confirm that visitors cannot browse its contents. Between updates, that directory should contain only index.php.
Seven advisories concern the Interactivity API, WordPress functionality that lets page elements react to visitors. KSES, the filtering system that controls which HTML users without unfiltered_html permission may save, allowed any data-* attribute and value. Interactivity directives use those attributes, so Contributors could place directives in posts that survived filtering and were then executed by the browser-side runtime when someone viewed the page. The resulting flaws included stored cross-site scripting, or stored XSS, where harmful browser code is saved in site content and later delivered to visitors.
The Interactivity API problems covered javascript: links, event-handler bindings already rejected by the PHP side, reserved keys such as __proto__ entering a context merge, unsafe bindings on object elements, and a CSS parser that repeatedly processed its input. The CSS case could freeze a visitor’s browser tab but did not exhaust the server. Other advisories covered object elements loading administration pages, prototype pollution, and stored XSS plus denial of service in bindings. Version 7.1.4 makes KSES remove bindings that could alter a previously validated value, restricts object-element bindings in the PHP directive processor, and makes the client runtime reject unsafe targets. Because the client runtime arrived in 6.4 and the PHP class followed in 6.5, WordPress lists both releases as affected by the same number of issues.
A related state-shadowing flaw arose because the Interactivity API used getElementById() to find a script containing its state. That function returns the first matching ID regardless of the element type, and WordPress printed the legitimate script in wp_footer after post content. A Contributor could therefore place an earlier element with the same ID in stored content and supply state to the runtime. WordPress 7.1.4 now verifies that the selected element is actually a script. Another Interactivity Router issue allowed stored XSS through uploaded text files and required an Author-level account with permission to upload files.
Two Customizer issues were also fixed. Selective refresh trusted data-customize-partial-* attributes from previewed content and passed an attacker-controlled selector to jQuery’s $() function. jQuery interprets a string beginning with a less-than sign as HTML to create, rather than a selector to find. WordPress now uses .find(), which only processes selectors. Separately, an anonymous preview request without a changeset UUID could adopt the newest unpublished changeset, regardless of its author, exposing its UUID and rendered preview. Changing settings remained protected by separate permissions. The fix requires the customize capability.
Several block-editor flaws involved content being interpreted again after filtering. The Categories block filtered a dropdown label and then used it as a sprintf() format string, allowing formatting directives to expand afterwards. The Image and Playlist blocks used attacker-influenced matched text as a preg_replace() replacement, where PHP could expand backreferences such as $0 and splice markup into an attribute. Those blocks now use the HTML API. Comments Pagination and Post Navigation Link blocks failed to escape their label attributes. A separate Categories block issue, the Image and Playlist hardening fix, and these unescaped labels respectively required Contributor, Author and Contributor access.
WordPress’s server and editor parsers also disagreed over whitespace in block delimiters. The PHP parser recognised six whitespace characters, while JavaScript also accepted non-breaking spaces, several Unicode spaces and a byte order mark.