WordPress 7.1.4: A No-Login Code Execution Bug in the Updater, and Attackers Were Probing Within 9 Minutes

On October 28, 2026, WordPress released 7.1.4, a security release that fixes 22 vulnerabilities. Fixes were backported to every branch back to 4.7. Most of the 22 are cross-site scripting bugs that need a logged-in Contributor or higher. One is different: a race condition in the core updater that can lead to remote code execution, with no account needed.

Wordfence rates that flaw CVSS 8.1 and says it affects WordPress 4.7 through 7.1.3. It deployed a firewall rule for it at 20:30 UTC on release day and recorded the first matching request nine minutes later. In the first 21 hours it counted more than 18,500 requests aimed at the vulnerable paths. Wordfence describes these as exploitation attempts and has not reported a confirmed compromise. No CVE has been published yet, and the flaw is not on CISA’s Known Exploited Vulnerabilities list.

How the Updater Bug Works

When WordPress installs a full core update, it first unpacks a complete copy of WordPress into a working folder under wp-content/upgrade/, then moves the files into place. That copy includes the WordPress installer, setup-config.php. Before 7.1.4 the working folders had predictable names.

For a few seconds during the update, the staged installer sits in a folder the web server will happily serve. If PHP files under wp-content/upgrade/ can be reached and executed over the web, as it is on many standard setups, an attacker who requests the staged installer at the right moment can get it to run their code on the server. They do not need an account, and the request never touches the normal WordPress login or permission checks.

The timing is hard, which is why the score is 8.1 and not higher. But attackers do not need to guess when you update: automatic background updates run on a schedule, and a bot that polls the staging paths over and over will eventually hit the window. The pattern Wordfence describes, a few sources polling small groups of sites for hours, is exactly that.

The fix in 7.1.4 adds random characters to the staging folder names, puts an index guard back in the folder, and stops staged configuration data from being copied into place.

The Other 21

• Stored cross-site scripting, mostly. In the Interactivity API, the Customizer, the Categories, Comments Pagination, Post Navigation, Image and Playlist blocks, block markup itself, and the privacy data erasure screen. Nearly all need a logged-in Contributor, Author or Editor, which matters most on sites with many writers or open registration.
• Unpublished Customizer changes could be seen by visitors who are not logged in. Useful to anyone wanting a preview of a redesign or a launch.
• A stored denial of service in the Interactivity API, and a permissions gap that let custom comment-moderator roles read and edit notes on posts they cannot edit.
• Updated root certificates. WordPress ships its own certificate bundle for outgoing HTTPS calls, and 7.1.4 removes the eMudhra root after that CA’s compromise. See our eMudhra post for the background.

The Fixed Version for Your Branch

Only the newest branch is actively supported, but the WordPress security team backported the fixes to every branch back to 4.7. Older branches are hit by fewer of the 22 because the affected code did not exist yet.

Did Your Site Update Itself?

Most WordPress sites install minor security releases on their own, and in our own scans most sites that show their version had already moved to a fixed release within two days. The ones that had not are the usual suspects:

• Automatic updates turned off, often by a plugin or by a WP_AUTO_UPDATE_CORE or AUTOMATIC_UPDATER_DISABLED line in wp-config.php that someone added years ago.
• Managed hosts that hold core updates back to test them first. Check your host’s status page.
• Sites deployed from Git or Composer, where the WordPress version is pinned in code and only changes when someone ships a new build.
• Failed updates. A full disk or wrong file permissions can make the background update fail without anyone noticing.

One awkward detail: the bug is in the update process, and the update to 7.1.4 is itself a core update. If you can, block PHP in wp-content/upgrade/ first (see below), then update.

What to Do

• Update now to the fixed version for your branch from the table. Dashboard → Updates → Update Now, or wp core update with WP-CLI.
• Confirm it finished. Dashboard → Updates should name the fixed version, and so should the footer of the admin screens.
• Stop PHP running in wp-content/upgrade/. Nothing in that folder ever needs to be served to a visitor. On Apache, add an .htaccess in it with Require all denied. On nginx, add a location ^~ /wp-content/upgrade/ { deny all; } block. This is worth keeping even after you patch.
• If you were not on a fixed release on October 28, look for signs of use. Wordfence suggests checking access logs for requests to PHP files under wp-content/upgrade/, and the site for unfamiliar administrator accounts, plugins nobody installed, and PHP files you did not put there.
• Then do the plugins. Core auto-updates do not cover plugins by default, and October brought 117 critical plugin CVEs.
• Rescan. The Exposure finding should clear.

What the Check Can and Cannot See

The scanner reads the WordPress version your site shows on its own: the generator tag and the version numbers on core script and style URLs. If your site shows a version older than its branch’s fixed release, you get a finding. If it hides the version, the scan cannot tell whether you are patched and will not guess, so check the dashboard. Either way it cannot see inside wp-content/upgrade/ during your next update, which is why the server rule above is worth adding.

Know the Day Your Version Falls Behind

Every domain in an InternetSecure account is scanned daily. When WordPress ships a security release and your site still shows the old version, the change lands in your alert digest, Slack, JIRA or Linear that day, with the version to move to. When the update lands, you hear about that too.

Create a free account to monitor your domains, or run a one-off check from the homepage scanner.

Sources: the WordPress 7.1.4 release documentation (the 22 fixes and the per-branch versions). The CVSS score, affected range and attack numbers are from Wordfence’s advisory, as reported by Brandefense and GBHackers, current as of October 30. No CVE had been assigned at the time of writing.