WordPress security updates should be treated as maintenance work, not a “wait and see” task. A recently disclosed WordPress Core weakness can expose a site during the short window when WordPress is unpacking a complete update. This WebCareSG guide explains what to check, how to patch it safely, and what to do if your logs show suspicious activity.
The issue affects older WordPress Core branches, but it is not a reason to run an exploit against your own site. A safe review starts with the installed version, update history, web-server logs, and the files that appeared recently.
What is the WordPress upgrade-window RCE?
During a complete WordPress Core update, the updater temporarily unpacks files in a staging area under wp-content/upgrade. The vulnerability is a race condition: if an unauthenticated attacker can discover and reach a temporary installer file before the update cleanup finishes, the attacker may be able to make the server execute PHP code.
The conditions are narrow, but the impact is serious. A successful attack could lead to an administrator account being added, malicious plugins or themes being installed, customer data being accessed, or the website being used to attack visitors. A firewall rule can reduce exposure, but it should not replace the WordPress Core update.
Which WordPress versions are affected?
The WordPress security advisory lists versions from 4.7.0 through 7.1.3 as affected. The recommended fix is the latest security release for the branch you use. The current 7.1 branch fix is WordPress 7.1.4.
| WordPress branch | Minimum fixed version |
|---|---|
| 7.1 | 7.1.4 |
| 7.0 | 7.0.8 |
| 6.9 | 6.9.11 |
| 6.8 | 6.8.12 |
| 6.7 | 6.7.11 |
| 6.6 | 6.6.11 |
| 6.5 | 6.5.14 |
| 6.4 | 6.4.14 |
| 6.3 | 6.3.14 |
| 6.2 | 6.2.15 |
| 6.1 | 6.1.16 |
| 6.0 | 6.0.18 |
| 5.9 | 5.9.20 |
| 5.8 | 5.8.19 |
| 5.7 | 5.7.21 |
| 5.6 | 5.6.23 |
| 5.5 | 5.5.24 |
| 5.4 | 5.4.25 |
| 5.3 | 5.3.27 |
| 5.2 | 5.2.30 |
| 5.1 | 5.1.28 |
| 5.0 | 5.0.31 |
| 4.9 | 4.9.35 |
| 4.8 | 4.8.34 |
| 4.7 | 4.7.39 |
If your version is older than the fixed version for its branch, treat the site as needing urgent maintenance. If the site is several major versions behind, plan a supported-version upgrade and test it on a backup or staging copy.
How to check your WordPress site safely
Step 1: Record the installed Core version
In WordPress, open Dashboard → Updates and record the WordPress version. If you have shell access and WP-CLI is installed, run:
wp core versionDo not use the generator meta tag or a public version scanner as your only source of truth. Those values can be removed or hidden.
Step 2: Compare the version with the fixed branch
Compare the result with the table above. For example, WordPress 7.1.3 is in the affected range, while 7.1.4 contains the security fix. An older branch is not automatically safe just because the site still loads normally.
Step 3: Check the upgrade directory without uploading a test file
Do not upload a PHP file, run a proof of concept, or try to reproduce remote code execution. A simple read-only request can show whether the directory is publicly reachable:
curl -sS -o /dev/null -w "%{http_code}\n" \
https://example.com/wp-content/upgrade/A 200 response or directory listing deserves immediate server-level review. A 403 or 404 is useful evidence, but it does not prove that a temporary file was never reachable during an earlier update.
Step 4: Review web-server logs
Search the access logs around the last Core update for requests to the upgrade directory or unexpected PHP files. Log locations differ by hosting provider; the following is an example for common Nginx and Apache paths:
sudo zgrep -Ein \
'wp-content/upgrade|wp-admin/upgrade\.php|setup-config\.php' \
/var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/nullLook for bursts of requests, unfamiliar user agents, repeated requests for PHP files, or requests that happened during an update. Preserve the relevant log lines before rotating or deleting logs.
Step 5: Check for changes made after the update
Review recent files, administrator accounts, plugins, and themes. These commands are examples; adjust the paths and date range for your hosting environment:
find wp-content -type f -name '*.php' -mtime -14 -print
wp user list --role=administrator
wp plugin list
wp core verify-checksumsUnexpected PHP files in uploads, new administrator accounts, an unknown plugin, or modified core files should be treated as investigation findings. A clean homepage does not rule out a persistent backdoor.
How to fix the vulnerability
Step 1: Take a backup and record the current state
Before changing files, take a tested database and file backup. Record the current Core version, active plugins, themes, PHP version, and recent log findings. If you already see signs of compromise, preserve a copy for investigation before cleaning anything.
Step 2: Apply the WordPress security update
Use Dashboard → Updates and install the fixed version for your branch, or use WP-CLI from the WordPress document root:
wp core update
wp core versionDo not force a major-version change on a production site without checking plugin, theme, PHP, backup, and staging compatibility. If the site is on an old branch, apply its listed security release first, then schedule a supported-version upgrade.
Step 3: Block direct web access to the upgrade staging folder
As defense in depth, deny HTTP access to wp-content/upgrade/ at the web-server layer. Ask your hosting provider to apply the equivalent rule if you do not manage the server. For Nginx, the rule is commonly placed inside the HTTPS server block:
location ^~ /wp-content/upgrade/ {
deny all;
return 403;
}For Apache, use the equivalent directory access control for that folder. Test the site and a normal WordPress update workflow after the change. This is an additional barrier, not a substitute for patching.
Step 4: Scan and investigate before declaring the site clean
Run a reputable malware and integrity scan, review unknown administrator accounts, and compare core files with a known-good release. If suspicious files or requests are found, do not simply delete the first file that looks unusual. Isolate the site, preserve evidence, rotate hosting, WordPress, database, SSH, FTP, and API credentials, and restore from a known-clean backup only after checking the persistence points.
Step 5: Verify the repair
Confirm the installed version is at or above the fixed version for its branch. Recheck the upgrade directory from an external connection, clear relevant page and CDN caches, test login and contact forms, and monitor access logs for renewed requests to upgrade or unexpected PHP paths.
What website owners should do today
- Check the exact WordPress Core version.
- Patch to the fixed release for that branch.
- Review the upgrade directory and web logs.
- Check administrator accounts, plugins, themes, and recently changed PHP files.
- Run an integrity or malware scan.
- Rotate credentials if there is any evidence of unauthorized access.
Sources and further reading
- WordPress 7.1.4 security release
- WordPress Core security advisory and fixed branch versions
- Wordfence technical analysis and response guidance
- The Hacker News report that prompted this guide
Security information changes quickly. Check the official WordPress advisory and your hosting provider's notices before applying changes to a critical production site.
