| Severity | HIGH |
| Threat Category | Vulnerability – Remote Code Execution (unauthenticated, upgrade-window race condition) |
| Affected Platforms | WordPress Core versions 4.7.0 through 7.1.3, covering the current release of every branch from 4.7 to 7.1. |
| CVE | CVE-2026-119977 |
| CVSS | 8.1 HIGH (v3.1) |
1. Overview
A high-severity remote code execution (RCE) vulnerability has been fixed in WordPress Core, the content management system behind a large share of the world’s websites. CVE-2026-119977 affects WordPress Core versions 4.7 through 7.1.3. During a full-package core upgrade, WordPress stages the new files in a predictable, web-accessible directory. An unauthenticated attacker who reaches that directory at the right moment during the brief upgrade window can execute code on the server. This is classified as a time-of-check to time-of-use (TOCTOU) race condition (CWE-367).
Wordfence, acting as the CVE Numbering Authority, rates the issue 8.1 (High) on CVSS version 3.1, with a network attack vector, no privileges and no user interaction, but high attack complexity because exploitation is only possible during a core upgrade that the attacker does not control. WordPress fixed the flaw in version 7.1.4, released on 28 October 2026, and is backporting security releases to older branches.
2. Who is Affected
Any organisation or individual running a self-hosted WordPress site on Core version 4.7 through 7.1.3 is affected. WordPress is the most widely used website platform in Bhutan and worldwide, used by government offices, businesses, schools and individuals, so the exposed population is very large.
Exploitation attempts are already being observed. Wordfence reports that attackers began probing for the vulnerable staging path within hours of the patch release and blocked many thousands of exploitation attempts in the first day; it reports no confirmed successful compromises, and the issue is not listed in the CISA Known Exploited Vulnerabilities catalogue. The severity is assessed as HIGH, balancing the following factors:
- The flaw allows a remote, unauthenticated attacker to execute code on the server, which means full site compromise. No credentials and no user interaction are required.
- Exploitation is only possible during the short window while WordPress is unpacking a full core upgrade, which Wordfence observed to last only seconds. This high attack complexity is why the CVSS score is 8.1 (High) rather than higher.
- Attackers overcome the narrow window by continuously polling target sites, so sites that update automatically are realistically exposed each time an update runs. Active probing is already underway following public disclosure.
- The malicious request goes directly to a PHP file in the staging directory without loading WordPress first, so a WordPress security plugin may never see it. Protection at the web-server level is therefore important.
3. How the Vulnerability Works
- Stage 1 – Root Cause
When WordPress installs a full-package core update, it extracts the new files, which include the WordPress installer, into a predictable directory inside the web-served wp-content/upgrade/ folder. The upgrader checks and then uses files in that location without protecting against a concurrent change, and on many servers the directory is reachable over the web during the upgrade. This is a time-of-check to time-of-use race condition (CWE-367).
- Stage 2 – Exploitation
An unauthenticated attacker repeatedly requests the predictable staging path while a core upgrade is running. If a request arrives during the brief window before WordPress finishes and cleans up, the attacker can interact with the staged WordPress installer and drive it to execute PHP code. The window lasts only seconds, so attackers use automated scripts that poll continuously to catch an upgrade in progress.
- Stage 3 – Impact
Successful exploitation gives the attacker code execution with the privileges of the web server process, which is a full compromise of the WordPress site. From there an attacker can read and modify site files and the database, steal credentials and personal data, deface or disable the site, install web shells and backdoors for persistent access, and attempt to pivot to other systems in the same hosting environment.
- Stage 4 – Fix and Disclosure
WordPress fixed the flaw in version 7.1.4, released on 28 October 2026, and is backporting security releases to all branches still eligible for security fixes (back to 4.7). According to Wordfence, the fix randomises the staging directory name, adds an index guard, and prevents unsafe promotion of staged configuration data. The issue was reported by Umut Bayram, and Wordfence published the CVE record on 31 October 2026.
4. Indicators to Watch For
- The site runs an affected WordPress version. Check in the admin dashboard under Dashboard → Updates, or with the WP-CLI command wp core version. Vulnerable if 4.7 through 7.1.3.
- Unexpected PHP files, or an unexpectedly persistent staging directory, under wp-content/upgrade/. This folder should normally be empty except briefly during an upgrade.
- Repeated web requests to paths under wp-content/upgrade/, especially to installer files such as setup-config.php, in the web server access logs, particularly bursts from a single source.
- New or unexpected administrator accounts, new PHP files elsewhere in the web root, modified core or theme files, and unexplained outbound connections from the web server.
- Because the malicious request can bypass WordPress and any security plugin, rely on web server logs and file integrity checks rather than plugin logs alone.
5. Recommendations
5.1. For organizations and government offices:
- First, deny web (HTTP) access to the wp-content/upgrade/ directory at the web server (for example an Apache or Nginx deny rule). This blocks the attack path without affecting the upgrade itself, which runs server-side, and should be applied before updating.
- Then update WordPress Core to 7.1.4 (or, on an older branch, to the backported security release for that branch as soon as it is available). Note that the act of updating from 7.1.3 runs the vulnerable upgrader, which is why the web-server block should be in place first. Upgrading to 7.1.4 is strongly preferred, since only the latest version is actively supported.
- Keep automatic background updates enabled. Once a site is on the fixed version, the exposure during future upgrades is removed.
- Inspect wp-content/upgrade/ for stray or unexpected PHP files, and review web server access logs for the request patterns in Section 4.
- Do not rely on a WordPress security plugin or application firewall alone, because the malicious request can reach a PHP file without loading WordPress. Web-server-level controls and patching are the dependable measures.
- If you find evidence of compromise, treat the server as compromised: isolate it, rotate all credentials, database passwords and secret keys, remove any web shells, and restore from a known-good backup.
5.2. For individuals (if applicable):
- If you run your own WordPress site, check your version under Dashboard → Updates and update to 7.1.4 immediately.
- If your site is on managed WordPress hosting, confirm with your provider that version 7.1.4 (or the fix for your branch) has been applied.
- Leave automatic updates turned on. The fix removes the exposure that the upgrade process currently carries, so staying on the latest version is the safest option.
6. Reporting
If you suspect your organization, device or account has been affected by this threat, or observe activity matching this pattern, please report it to BtCIRT at cirt@btcirt.bt
7. Sources and References
- CVE-2026-119977 – CVE Record: WordPress Core 4.7.0 – 7.1.3 Unauthenticated Upgrade-Window Staged-Installer Remote Code Execution (Wordfence, CNA) (31 October 2026). https://www.cve.org/CVERecord?id=CVE-2026-119977
- Wordfence Threat Intelligence – CVE-2026-119977 vulnerability record (31 October 2026). https://www.wordfence.com/threat-intel/vulnerabilities/id/4b4da0cf-d9f4-47c4-a0e8-6c4dc5a6f250?source=cve
- WordPress 7.1.4 (security release announcement, WordPress advisory GHSA-4w3m-c66w-69mg) (28 October 2026).
https://wordpress.org/news/2026/10/wordpress-7-1-4/ - WordPress Core 7.1.4 Fixes an Unauthenticated Upgrade-Window Race RCE (CVE-2026-119977). Update and Block wp-content/upgrade/ (Rescana) (31 October 2026). https://www.rescana.com/post/wordpress-core-7-1-4-upgrade-staging-race-rce