WordPress 7.1.4 fixes a security flaw in core updates

WordPress 7.1.4 fixes the security flaw in the core update process, but installing the patch does not replace server-side protection for temporary upgrade files. If your site runs an older branch, you need its corresponding security release and a web server configuration that prevents public access to wp-content/upgrade/.

The release arrived on 28 October 2026, according to WordPress.org. It addresses 22 vulnerabilities covered by 17 security advisories, as detailed by Patchstack.

Check the version your site is actually running

Sign in to WordPress and open Dashboard > Updates. Look at the installed core version rather than relying on an update notification or assuming a background update has finished.

The official WordPress announcement explains that the release can be installed from the dashboard or downloaded directly. Sites supporting automatic background updates may receive it automatically, but the installed version still needs checking.

Treat each installation separately. A business website, an online shop and a staging environment may run different releases even when they use the same hosting provider.

Use the following checks before marking the maintenance task as complete:

Older WordPress branches have their own patched releases

A site does not necessarily need to display version 7.1.4 to contain this particular fix.

The WordPress security advisory on GitHub identifies affected versions from 4.7.0 through 7.1.3, with fixes backported across the maintained branches.

The patched releases include:

• 7.1.4 for the 7.1 branch.
• 7.0.8 for the 7.0 branch.
• 6.9.11 for the 6.9 branch.
• 6.8.12 for the 6.8 branch.
• 4.7.39 for the 4.7 branch.

Other branches have their own corresponding releases, listed in the official advisory. Check the exact version rather than assuming that any older installation is protected.

WordPress 4.6 and earlier do not receive this fix, according to Patchstack. If your site is still on one of those releases, plan a move to a patched branch and assess compatibility before making the switch.

Keeping track of software support makes these decisions easier. Our article on technology stack support schedules covers that broader maintenance issue.

The vulnerability exposed files during core updates

During a full core update, WordPress extracted its replacement files into a predictable directory beneath wp-content/upgrade/.

Where that location was publicly accessible, somebody without a WordPress account could attempt to reach the temporary files while extraction was taking place. Successfully exploiting that narrow opportunity could lead to remote code execution.

The mechanism is described in the official WordPress security advisory.

An attack depends on several conditions. A full core update must be running, the temporary directory must be accessible over the web, and the request must arrive during a window lasting only seconds.

WordPress rates the vulnerability as low severity, while Patchstack describes the attack complexity as high. That difficulty matters when assessing risk, but it does not remove the need to patch an issue capable of allowing code execution.

The release also addresses stored cross-site scripting vulnerabilities involving blocks, the Customizer, personal data erasure and the Interactivity API. A stored denial-of-service issue affecting the Interactivity API is also included, as confirmed by WordPress.org.

Deny access to wp-content/upgrade/ in Apache or Nginx

The main server-side action is to prevent public requests from reaching the upgrade directory, even after installing the patched WordPress release.

Both Patchstack and Rescana recommend blocking web access to wp-content/upgrade/.

For Apache, the restriction should be applied through its access configuration. For Nginx, use an equivalent server rule that denies requests to that path.

The intention is to block HTTP access, not to stop WordPress from using the directory internally when performing updates.

Once the rule is in place, verify that the directory cannot be listed and that files within it cannot be served directly. Disabling directory listings alone is not sufficient protection.

A firewall implemented in PHP cannot reliably protect this path.

If your hosting package does not give you access to the Apache or Nginx configuration, ask the hosting provider to apply and test the restriction.

Finish with a documented maintenance check

For a commercial website, confirm that the update completed, record the installed version and test the server restriction from outside the hosting environment.

If the site relies on plugins or custom development, it is also worth checking the PHP environment during the same maintenance review. Our article on updating PHP in WordPress after a security issue covers that separate decision.

Record which version is installed, how the directory is protected and who is responsible for checking the configuration. For handling reported security issues, see our article on vulnerability reporting and the Cyber Resilience Act.

This week, check the installed version of every WordPress site you manage and arrange a server-level access test for wp-content/upgrade/. If you need to assess a website or online shop before updating, tell Contrast 3D what your current setup looks like and what needs checking.