WordPress Core RCE Update: Attackers Lie in Wait on the Upgrade Window

WordPress 7.1.4, released October 28, 2026, is a WordPress core RCE update. It closes a flaw that lets someone with no login run code on a site while a full core upgrade is unpacking. Within a day, Wordfence had blocked 62,969 attempts to hit that window, so how you apply the patch matters almost as much as applying it.

What is the WordPress core RCE, and who is affected?

Every WordPress site running core versions 4.7 through 7.1.3 is in scope. The fix is WordPress 7.1.4, released on October 28, 2026. The flaw is unauthenticated remote code execution: the attacker needs no account, no admin session and no plugin bug to start from.

The vulnerability carries a CVSS score of 8.1. The published material gives neither the CVSS version nor the vector string, so treat the number as a severity signal only, not a description of how the attack works.

There is also no CVE identifier, which breaks identifier-based tracking. If your patch routine waits for a CVE to show up in a scanner or vulnerability inventory, this one can slip past. Check the version number directly.

WordPress 4.7 shipped in December 2016, so the affected range covers nearly a decade of releases. A site that has quietly sat on an old branch since then is just as affected as one that missed last month’s point release.

The public technical description comes from Wordfence, through Alex Thomas, who leads its Threat Response Team, and was reported by The Hacker News. The coverage doesn’t say who originally found the flaw or how it was disclosed, and we won’t guess.

If you followed our coverage of the Comment2Shell WordPress flaw, notice the difference. That attack started with content the site accepted from a visitor. This one doesn’t depend on anything the site accepts. What the attacker needs is timing.

Why does a normal core update open a race window?

The race window exists because WordPress unpacks a full new release into a predictable folder under wp-content/upgrade before copying the files into place, and that temporary copy includes the WordPress installer.

During a full-package core update (as opposed to a smaller partial update), WordPress downloads the complete archive and extracts it there. For a short time, a second, complete copy of WordPress sits inside your site’s directory tree.

On many servers that folder can be reached over HTTP, and PHP files in it will run. The installer has a well-known filename, setup-config.php, and that is the file attackers keep requesting.

Wordfence puts the root cause this way: “predictable, web-accessible staging paths used during full-package core upgrades” make it possible “for unauthenticated attackers to execute code on the server during the upgrade window.” Thomas adds that an attacker “who requests the installer at precisely the right moment can interact with the staged WordPress copy and progress to PHP code execution.”

All four of these conditions must hold at once:

• The site is applying a full-package update that contains the installer files.
• The staging tree is reachable from the web, and PHP executes there.
• The staging path is predictable or has been discovered.
• The attacker finishes before WordPress deletes the temporary files.

Timing is the limit. In normal lab conditions, Wordfence saw the window last only seconds. A busy shared server may take longer to finish an update than a clean lab machine, but no field measurements have been published.

Hosting configuration changes the exposure significantly. A server that refuses to execute PHP under wp-content/upgrade breaks the second condition outright, no matter how the update is started. We are deliberately not describing how the installer interaction turns into code execution; the vendor advisory is the right place for those details.

What did Wordfence see in the first 24 hours?

Wordfence blocked 62,969 attempts against the vulnerable paths in roughly the 24 hours before the October 30 report, and the attempts began shortly after the October 28 patches went out.

That averages about 44 attempts a minute across Wordfence’s whole protected base, not per site.

The more telling detail is behavior. “Two of the largest sources repeatedly polled small groups of sites for roughly 14.5 hours, behavior consistent with trying to catch the brief upgrade window,” Thomas said. Against a window measured in seconds, a poller that never stops gets thousands of chances to land at the right moment.

The calendar works in the attackers’ favor too: the days right after a patch are exactly when site owners run updates.

Other sources took a wider approach. They “tested many staging-directory and version-name variations,” which means they understand how the folder names are built and are trying the likely ones. This is the same automated, pattern-driven reconnaissance we described in how hackers find and target vulnerable websites, pointed at a much narrower target.

“Not every request used the exact vulnerable path, but the sustained polling and exact-layout probes show that attackers quickly understood the race condition and began targeting it.” (Alex Thomas, Wordfence)

Here is what the report does not say. It names no threat actor, campaign or country. It does not confirm that any site was compromised. Every figure refers to blocked or targeted attempts, not breaches.

How should you update to WordPress 7.1.4 safely?

Update core to 7.1.4 through the normal supported process, but first disable PHP execution in the staging folder so the update doesn’t expose the installer to pollers. Plugin and theme updates do nothing here. This is a core fix.

1. Confirm your version. Check Dashboard, then Updates, or run wp core version from the WordPress root. Anything from 4.7 to 7.1.3 needs the update.
2. Back up first. Copy the files and the database somewhere off the server. If you think the site may already have been touched, preserve the access logs and take a host snapshot before changing anything. Updating and cleaning up destroys the timing evidence.
3. Block PHP under wp-content/upgrade on Apache. On Apache-compatible servers that honor .htaccess, a deny rule for PHP files in that folder does the job.
4. Block it separately on Nginx. Nginx ignores .htaccess entirely, so the restriction has to go into the active server configuration. An Apache rule copied onto an Nginx host leaves the folder exposed. On shared hosting, ask your provider to confirm the block is in place.
5. Don’t assume your update tool avoids the folder. WP-CLI unpacks into wp-content/upgrade by default, just like the dashboard updater. If your host runs a managed updater, ask where it stages files; the PHP block is your safeguard either way.
6. Test big jumps. Going from a 4.x or 5.x branch to 7.1.4 can break old plugins. Rehearse on a staging copy, then update production.
7. Confirm cleanup. After the update, wp-content/upgrade should not contain a leftover copy of WordPress. If you find one, preserve it for review, then remove it.
8. Rotate reused credentials. If the admin, FTP or hosting passwords are shared anywhere else and your logs show probing, change them.

Automatic background updates may already have moved you to 7.1.4. Check the version instead of assuming. An automatic update runs through the same unpacking step, so having auto-updates on doesn’t protect you during it. Blocking PHP in the staging folder does.

What should you hunt for after the patch?

Look for requests to PHP files under wp-content/upgrade, especially setup-config.php. Then check for administrator accounts, plugins and PHP files nobody on your team created. No hashes, IP addresses or domains were published, so a blocklist won’t help here. The evidence has to come from your own site.

Access logs

Search your Apache or Nginx logs for wp-content/upgrade and setup-config.php, including URL-encoded forms. For each hit, note the source IP, the folder name used, the method, the status code and the response size. Then look at what the same IP requested next.

A request that arrived while no update was running had nothing to reach. One that landed in the seconds your update ran, followed by requests to a new or unusual PHP path, deserves a full investigation.

A 200 response alone proves nothing, and neither does a blocked request. Standard access logs don’t record POST bodies, so the full picture comes from correlating logs with files on disk.

Accounts, components and files

• Run wp user list --role=administrator --fields=ID,user_login,user_email,user_registered and confirm each admin with the site owner.
• List plugins and themes with wp plugin list and wp theme list, and check the mu-plugins folder, which the dashboard does not display.
• Look for PHP files in uploads and for files modified around your update time.
• Run wp core verify-checksums. It compares core files with WordPress’s published checksums. It does not check plugins, themes, uploads, users or the database, so a clean result is not a clean bill of health.

From our cleanup work: the first suspicious request is rarely what gives an intruder away. What does is the second admin account registered in the middle of the night, or a PHP file in uploads named to look like a cache file. On shared hosting, check every site that runs under the same system account. Cleaning only the targeted install often leaves a foothold in the site next door.

Warning: never request the staged installer on a production site to see whether you are vulnerable. Interacting with it can rewrite configuration and database state. Check the version number and your server’s PHP rules instead.

What should you do if the site already looks wrong?

Treat it as an incident, not a patching job. Updating to 7.1.4 closes the vulnerable path, but it won’t remove an admin account, plugin, webshell or database change that an intruder already planted.

Take the site offline or put it behind maintenance mode. Preserve logs and a snapshot. Patch core, then restore from a backup you know predates the suspicious activity, or clean the site thoroughly if no such backup exists.

Code execution as the web-server user exposes everything in wp-config.php: the database credentials and the authentication keys and salts. Rotate all of them, which also logs out every existing session. If other sites share the hosting account, how far an intruder could reach depends on file ownership and isolation, so check those sites too.

For the next update, and the next plugin flaw, two controls narrow the exposure. A web application firewall can refuse requests to staging paths and installer files outright. File-change monitoring flags a new PHP file within minutes instead of weeks. Our website antivirus and monitoring covers the second; a firewall protection package covers the first.

What is still unknown?

Several basics are still unanswered. No CVE has been assigned, and the CVSS version and vector are unpublished. The original reporter is not named. No attacker has been attributed. Nobody has confirmed a successful compromise, and nobody has said how long the window lasts on real production hosts rather than in a lab.

Until those answers arrive, assume the polling continues: patch, close PHP execution in the staging folder, and check your logs for the update window you already went through.

FAQ

Is WordPress 7.1.4 a security update?

Yes. It fixes an unauthenticated remote code execution flaw in core that affects versions 4.7 through 7.1.3. Updating plugins or themes does not fix it.

Can an attacker exploit this without a WordPress login?

Yes. The flaw is unauthenticated. The attacker needs no account, only a request to the staged installer that lands while a full core update is unpacking.

Can this be exploited when nobody is updating the site?

No. A full-package update must be unpacking, the staging tree must be web-reachable with PHP enabled, the path must be predictable, and the attacker must act before cleanup. Outside an update there is nothing to reach.

Will automatic background updates protect me?

They will bring you to 7.1.4, but the automatic update runs through the same unpacking step. Blocking PHP execution under wp-content/upgrade is what protects you during that step.

What should I search for in my logs?

Requests to PHP files under wp-content/upgrade, especially setup-config.php, including URL-encoded variants. Check whether they line up with the time of your update and what the same IP requested next.

If your logs show hits on wp-content/upgrade around your last update, or an admin account you don’t recognize, SiteGuarding can check and clean the site and put a firewall in front of it. See protection options.