CVE-2026-119977: WordPress Core Update Race RCE Exploited, in CISA KEV

This week in our InSEKurity of the Week series: the content management system behind roughly four out of ten websites on the internet. On October 28, 2026, WordPress shipped security release 7.1.4 with 22 fixes. The most serious one is CVE-2026-119977, a time-of-check to time-of-use (TOCTOU) race condition in the core updater that lets an unauthenticated attacker execute code on the server — not because of a plugin, not because of a weak password, but because the site updated itself. On November 3, CISA added the flaw to its Known Exploited Vulnerabilities catalog.

The mechanism is almost elegant. During a full-package core update, WordPress extracts the new release into a folder below wp-content/upgrade/ whose name an attacker can predict. That folder is usually served by the web server, and the extracted release contains WordPress’s own installer, setup-config.php. For a few seconds, a second, unconfigured copy of WordPress is reachable over HTTP. An attacker who hits it in that window can plant a wp-config.php pointing to their own database — and the updater then copies that file over the live configuration.

Two things make this week’s entry more than a curiosity. First, the irony: the very update that delivers the fix runs the old, vulnerable code — so the safe order is block first, then update. Second, the scale: Wordfence counted more than 18,500 malicious requests against staged installer paths within 21 hours of disclosure. The WordPress project itself rates the issue Low; CISA, Wordfence and the attackers clearly see it differently.

🚨 Summary

CVE ID: CVE-2026-119977 — “WordPress Core 4.7.0 - 7.1.3 - Unauthenticated Upgrade Window Staged Installer Remote Code Execution” (Wordfence)
CVSS 3.1 Score: 8.1 High (Wordfence as CNA), vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. The WordPress project’s own advisory rates it Low
CWE: CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition
Vendor Advisory: WordPress 7.1.4 Security Release (2026-10-28) and GHSA-4w3m-c66w-69mg (2026-10-29)
Affected Software: WordPress Core 4.7.0 through 7.1.3 — every branch from 4.7 to 7.1 before its security backport. The vulnerable updater logic dates back to WordPress 2.7; versions 2.7 to 4.6 receive no fix
Attack Vector: Network — an HTTP request to the staged installer setup-config.php below wp-content/upgrade/ while a core update is running
Authentication Required: None
Preconditions: A full-package core update must be in progress (manual, automatic or via WP-CLI), wp-content/upgrade/ must be reachable over HTTP with PHP execution, and the attacker must win a window that lasted seconds in lab tests
Impact: Replacement of the live wp-config.php, takeover of the site via a fresh installation, and PHP code execution with the web server’s privileges
Patch Status: Available — 7.1.4 and backports for all branches down to 4.7.39
Exploitation Status: Actively exploited per CISA; Wordfence reports mass probing since the day after the release
CISA KEV: Listed since 2026-11-03; federal due date 2026-11-06; known ransomware use: unknown

🖥️ What is WordPress?

WordPress is the most widely used content management system in the world. According to W3Techs figures, it runs around 40 percent of all websites — from personal blogs and SME homepages to newsrooms, online shops built on WooCommerce, and the marketing sites of large enterprises. It is open source, written in PHP, backed by MySQL/MariaDB, and extended by tens of thousands of plugins and themes.

What sets WordPress apart from most enterprise software is how it updates: since version 3.7, minor and security releases are installed automatically in the background by default. That is normally one of the best security features in the ecosystem. With CVE-2026-119977, it means the vulnerable moment arrives on its own — unattended, on thousands of sites at once, often in the middle of the night.

Typical Use Cases

Corporate websites and landing pages — often managed by marketing teams or agencies rather than IT
E-commerce with WooCommerce, including customer accounts and order data
Intranets, knowledge bases and blogs for internal and external communication
Shared hosting and managed WordPress platforms — thousands of sites per server
Headless CMS setups, where WordPress feeds content to separate front-ends via its REST API

Why WordPress Keeps Landing in KEV

CVE-2026-119977 is the fourth WordPress core vulnerability added to CISA KEV since July 2026 — after CVE-2026-60137 and CVE-2026-63030 (the “wp2shell” chain, July 21) and CVE-2026-87902 (September 25). Before July, the only WordPress entries in KEV were three plugin flaws from 2021. Core is no longer the safe part of a WordPress installation by default.

🔍 Technical Analysis

Vulnerability Description

A WordPress core update follows five steps: download the release package, extract it below wp-content/upgrade/, verify the known core files, copy the new release over the live site, and delete the temporary folder. The weakness sits between step 2 (extract) and step 4 (copy).

During that window, the staging folder contains a complete, unconfigured WordPress — including the installer wordpress/wp-admin/setup-config.php. If wp-content is below the web root and PHP is executed there (the default on most hosts), that installer can be called over HTTP. Picus Security researcher Umut Bayram, who reported the flaw, showed that an attacker can use it to write a new wp-config.php into the staging tree. The updater then copies that file over the live configuration.

Root Cause Analysis

Picus identifies three weaknesses that only become exploitable together:

Predictable staging path. WP_Upgrader::unpack_package() in wp-admin/includes/class-wp-upgrader.php extracts the package with unzip_file() into wp-content/upgrade/<package-name>/. In WordPress 5.9.0 to 7.1.3, the folder name is derived again from the package’s filename (via the Content-Disposition header). Versions 4.4.0 to 5.8.x added a six-character random suffix and are only exploitable if the path leaks another way; versions 2.7 to 4.3 use fixed or filename-derived names as well.
Installer that does not look up. setup-config.php only checks wordpress/wp-config.php and <package-name>/wp-config.php for an existing configuration. It does not walk up to the live wp-config.php in the site root — so from inside the staging folder, the site looks “not yet configured”.
wp-config.php was not on the skip list. update_core() in wp-admin/includes/update-core.php builds a skip list (wp-content, wp-includes/version.php) and checks files against get_core_checksums(). wp-config.php is neither in the manifest nor on the skip list, so a staged copy is handed to copy_dir() and overwrites the live file.

Unexpected files in the staging tree are not rejected — the verification step only checks the files WordPress expects.

Attack Vector

The attack requires a qualifying package: the full, no_content and new_bundled packages contain the installer files. Partial and rollback packages only qualify if they ship setup-config.php, wp-config-sample.php, wp-settings.php and related files.

# ILLUSTRATIVE ONLY -- attack flow as described by Picus Security; NOT a functional exploit.
# No public weaponized exploit is referenced in this article.

  Victim site (core update running)            Attacker
  ---------------------------------            --------
  1. download wordpress-<ver>.zip
  2. unzip -> wp-content/upgrade/<package-name>/wordpress/...
                    |
                    |  <-- 3. polls the predictable path:
                    |        /wp-content/upgrade/<package-name>/wordpress/wp-admin/setup-config.php
                    |  <-- 4. submits DB settings of an attacker-controlled, empty database
                    v        -> staged wordpress/wp-config.php is written
  5. verify known core files (extra files are not rejected)
  6. copy_dir() -> staged wp-config.php overwrites the live wp-config.php
  7. delete staging folder
                    |
                    v
  Site now connects to the attacker's empty DB and shows the installer
                    |  <-- 8. attacker completes installation, becomes first administrator
                    |  <-- 9. uploads a plugin -> PHP code execution as the web server user

What defenders will see in their logs is the probing in step 3: requests for PHP files under /wp-content/upgrade/. Because the request goes directly to a staged PHP file, a firewall running inside WordPress never sees it — only an edge or web server-level control can block it.

The Fix — and the First-Update Gap

WordPress 7.1.4 changes three things:

The staging folder gets a 16-character random suffix, so it can no longer be guessed.
wp-content/upgrade/index.php is preserved (and recreated if missing) to prevent directory listings from revealing the path.
wp-config.php is added to the skip list in update_core().

The catch: extraction runs in the code that is already installed. Updating an unpatched site to 7.1.4 still uses the predictable path. The new update-core.php prevents the configuration from being overwritten, but Picus points out that the staged installer is still reachable during that one update. That is why the recommended order is to deny web access to wp-content/upgrade/ first and update second. The same applies to wp core update in WP-CLI, which uses the same code path.

Exploitation in the Wild

2026-10-29 — One day after the release, Wordfence publishes its warning and begins blocking requests to staged installer paths; more than 18,500 malicious requests follow within the first 21 hours. Wordfence observed attackers probing many variations of the path.
2026-10-31 / 11-01 — In a weekend update, Wordfence reports having “blocked 13,095 attacks targeting this vulnerability in the past 24 hours” (BleepingComputer).
2026-11-03 — CISA adds CVE-2026-119977 to KEV with a three-day federal deadline. CISA gives no details on observed compromises.

The Wordfence numbers count requests, not successful compromises — a single attacker has to hit the moment a specific site updates. But attackers do not need precision when they can simply poll thousands of sites continuously and let the background updater open the window for them.

Post-Exploitation Impact

Site takeover — the attacker becomes the first administrator of a WordPress instance running on the victim’s server.
PHP code execution with the web server’s privileges via plugin or theme upload — web shells and persistent backdoors follow.
Loss of the original configuration — the live wp-config.php, including database credentials and salts, is overwritten; the site breaks or shows the installation screen.
Access to the file system — wp-content/uploads, backups, other web applications and, on shared hosting, potentially neighbouring sites under the same user.
Abuse of the domain — SEO spam, malware distribution, phishing pages and redirects under a trusted name.
Pivoting from the web server into internal networks where the server has more reach than it should.

📊 Impact Assessment

Immediate Impact

Unauthenticated RCE on any WordPress site whose upgrade folder is web-reachable, during every full-package core update
The window reopens on every update — including unattended background updates
Mass scanning is already under way, and the request needs no credentials, no user interaction and no plugin

Affected Versions

Branch	Vulnerable	Fixed in
7.1	7.1.0 - 7.1.3	7.1.4
7.0	7.0.0 - 7.0.7	7.0.8
6.9	6.9.0 - 6.9.10	6.9.11
6.8	6.8.0 - 6.8.11	6.8.12
6.7	6.7.0 - 6.7.10	6.7.11
6.6	6.6.0 - 6.6.10	6.6.11
6.5	6.5.0 - 6.5.13	6.5.14
6.4	6.4.0 - 6.4.13	6.4.14
6.3	6.3.0 - 6.3.13	6.3.14
6.2	6.2.0 - 6.2.14	6.2.15
6.1	6.1.0 - 6.1.15	6.1.16
6.0	6.0.0 - 6.0.17	6.0.18
5.9	5.9.0 - 5.9.19	5.9.20
5.8	5.8.0 - 5.8.18	5.8.19
5.7	5.7.0 - 5.7.20	5.7.21
5.6	5.6.0 - 5.6.22	5.6.23
5.5	5.5.0 - 5.5.23	5.5.24
5.4	5.4.0 - 5.4.24	5.4.25
5.3	5.3.0 - 5.3.26	5.3.27
5.2	5.2.0 - 5.2.29	5.2.30
5.1	5.1.0 - 5.1.27	5.1.28
5.0	5.0.0 - 5.0.30	5.0.31
4.9	4.9.0 - 4.9.34	4.9.35
4.8	4.8.0 - 4.8.33	4.8.34
4.7	4.7.0 - 4.7.38	4.7.39
2.7 - 4.6	updater logic affected	no fix — upgrade to a supported branch

Source: GHSA-4w3m-c66w-69mg. WordPress only actively supports the latest branch; the backports are a courtesy.

Affected Environments

Shared hosting and agency platforms with many WordPress sites, standard document roots and automatic updates — the most attractive target for automated polling
Self-hosted WordPress on Apache or nginx where wp-content sits below the web root and PHP runs in every directory
Sites with web servers that can open outbound database connections — the published chain needs the server to reach an attacker-controlled database
Sites without an edge WAF — WordPress security plugins do not see requests to the staged file

Managed platforms that disable core updates in the application, serve wp-content/upgrade/ as non-executable, or deploy WordPress as an immutable image are much less exposed.

Attacker Profiles

Opportunistic botnet operators building SEO spam, malware-hosting and phishing infrastructure on trusted domains
Initial access brokers collecting web shells on corporate web servers to resell
Ransomware and data-theft actors — the wp2shell chain earlier this year was used to steal data from small businesses and government organisations

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

1. Find out which WordPress versions you run.

# With WP-CLI: prints the installed core version, e.g. "7.1.3"
wp core version --path=/var/www/html

# Without WP-CLI: read the version straight from wp-includes/version.php
grep '^\$wp_version' /var/www/html/wp-includes/version.php

# Hosting servers: list the version of every WordPress installation below /var/www
find /var/www -path '*/wp-includes/version.php' -exec grep -H '^\$wp_version' {} \;

Compare the result with the “Fixed in” column above.

2. Deny web access to wp-content/upgrade/ — before you update. Do not place an .htaccess file inside wp-content/upgrade/: the unpatched updater cleans that folder and deletes it.

# nginx: inside the server { } block of each WordPress site.
# The ^~ modifier stops regex locations (such as the usual "location ~ \.php$")
# from matching first, so PHP files below this path are never executed.
location ^~ /wp-content/upgrade/ {
    deny all;
}

# Apache 2.4: in the virtual host configuration (adjust the path to your document root)
<Directory "/var/www/html/wp-content/upgrade">
    Require all denied
</Directory>

# Apache, if you can only edit the .htaccess in the WordPress root directory
# (requires AllowOverride FileInfo). Returns 403 for everything below the path.
RedirectMatch 403 ^/wp-content/upgrade/

# Check the configuration syntax and reload the web server
sudo nginx -t && sudo systemctl reload nginx
# Apache on Debian/Ubuntu (use "httpd" instead of "apache2" on RHEL-based systems)
sudo apachectl configtest && sudo systemctl reload apache2

# Verify: a request below the upgrade folder must now return 403 (before: 404 or 200)
curl -s -o /dev/null -w '%{http_code}\n' https://www.example.com/wp-content/upgrade/probe.php

3. Update WordPress core.

# WP-CLI: update to the latest release (7.1.4 at the time of writing).
# Only run this AFTER step 2 -- the update itself runs the old, vulnerable code.
wp core update --path=/var/www/html

# Staying on an older branch? --minor only installs the latest minor release of the
# current branch (e.g. 6.9.10 -> 6.9.11)
wp core update --minor --path=/var/www/html

# Apply any database changes and confirm the new version
wp core update-db --path=/var/www/html
wp core version --path=/var/www/html

If you prefer not to run the updater at all, update manually as described in the WordPress documentation: unpack the release outside the web root and replace the core files, but never wp-config.php or wp-content.

# Download and verify the release outside the web root
cd /tmp && curl -sSO https://wordpress.org/wordpress-7.1.4.tar.gz
curl -sS https://wordpress.org/wordpress-7.1.4.tar.gz.sha1   # compare with the next line
sha1sum wordpress-7.1.4.tar.gz
mkdir -p /tmp/wp-update && tar -xzf wordpress-7.1.4.tar.gz -C /tmp/wp-update

# Replace wp-admin and wp-includes completely (removes files dropped from core)
rsync -a --delete /tmp/wp-update/wordpress/wp-admin/ /var/www/html/wp-admin/
rsync -a --delete /tmp/wp-update/wordpress/wp-includes/ /var/www/html/wp-includes/

# Copy the root files -- never wp-config.php, never wp-content
rsync -a --exclude 'wp-content/' --exclude 'wp-admin/' --exclude 'wp-includes/' \
      --exclude 'wp-config.php' /tmp/wp-update/wordpress/ /var/www/html/

# Run the database upgrade
wp core update-db --path=/var/www/html

Run the rsync commands as the user that owns the site files, or fix ownership afterwards. Keep the block from step 2 in place permanently — it costs nothing.

Detection Measures

# 1. Requests for PHP files below wp-content/upgrade/ (nginx; use /var/log/apache2/access.log*
#    on Debian/Ubuntu Apache or /var/log/httpd/access_log* on RHEL). zgrep also reads rotated .gz logs.
zgrep -hE '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log*

# 2. Source IPs behind those requests, most active first
zgrep -hE '/wp-content/upgrade/[^ ]*\.php' /var/log/nginx/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# 3. Requests to the staged installer that were ANSWERED with HTTP 200
#    (combined log format: field 9 is the status code). Treat any hit as a likely compromise.
zgrep -hE '/wp-content/upgrade/[^ ]*setup-config\.php' /var/log/nginx/access.log* \
  | awk '$9 == 200'

# 4. PHP files left in the upgrade folder -- outside a running update it should be (almost) empty
find /var/www -path '*/wp-content/upgrade/*' -name '*.php' -type f -ls

# 5. Is wp-config.php still yours? Check the database host/name and when the file last changed
wp config get DB_HOST --path=/var/www/html
wp config get DB_NAME --path=/var/www/html
stat -c '%y %n' /var/www/html/wp-config.php

# 6. Administrators -- look for accounts nobody created, or a "fresh" install with a single admin
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered --path=/var/www/html

# 7. Plugins -- look for plugins nobody installed
wp plugin list --path=/var/www/html

# 8. Core file integrity against WordPress.org checksums (does not cover wp-config.php or wp-content)
wp core verify-checksums --path=/var/www/html

# 9. PHP files in wp-content changed since the 7.1.4 release
find /var/www/html/wp-content -name '*.php' -newermt '2026-10-28' -ls

A very visible indicator: if a site showed the WordPress installation screen or suddenly ran with empty content after a core update, assume it has been hit.

# Sigma rule -- request for a PHP file in the WordPress upgrade staging folder.
# Starting point only: legitimate updates do not request these files over HTTP,
# but tune for your environment before alerting.
title: Request to PHP File in WordPress Upgrade Staging Folder (CVE-2026-119977)
status: experimental
description: Detects HTTP requests for PHP files below wp-content/upgrade/, as used to reach the staged installer during a core update.
references:
    - https://www.picussecurity.com/resource/blog/cve-2026-119977-when-updating-wordpress-becomes-the-vulnerability
logsource:
    category: webserver
detection:
    selection:
        cs-uri-stem|contains: '/wp-content/upgrade/'
        cs-uri-stem|endswith: '.php'
    condition: selection
falsepositives:
    - Unknown
level: high

If you find a likely compromise: take the site offline, preserve logs and the file system, restore wp-config.php and the database from a known-good backup, rotate the database password and the authentication salts, and rebuild from clean sources rather than trying to clean in place.

Long-term Security Improvements

Keep wp-content/upgrade/ permanently non-web-accessible and disable PHP execution in wp-content/uploads/ — writable folders should never execute code.
Put a WAF in front of WordPress, not only inside it. Plugin-based firewalls are blind to requests that bypass WordPress.
Restrict outbound connections from web servers. A web server that cannot reach arbitrary databases on the internet breaks the published attack chain.
Consider immutable deployments — build WordPress with Composer or as a container image, deploy the result, and disable in-place core updates on production.
Inventory every WordPress site, including the ones run by marketing or an agency. You cannot patch what you do not know about.
Monitor file integrity of wp-config.php and core files, and alert on new administrator accounts.
Retire unsupported branches: versions 2.7 to 4.6 will never be fixed, and only the latest branch is officially supported.

⚠️ Why is this Critical?

Confirmed exploitation — CISA KEV listing with a three-day federal deadline.
Unauthenticated, no plugin required — the flaw is in core, so every standard installation is a candidate.
The patch process is the attack surface — automatic updates open the window on their own, and the update to 7.1.4 is itself still exposed.
Mass probing within a day — tens of thousands of requests against staged installer paths.
Invisible to in-app protection — WordPress security plugins do not see the request.
The vendor rates it Low — a rating that can lead teams to deprioritise exactly the flaw attackers are scanning for.

📅 Timeline and Disclosure

2008 — The affected updater logic appears in WordPress 2.7 (per Picus).
2026-10-28 — WordPress releases 7.1.4 with 22 security fixes, including the upgrade race reported by Umut Bayram (Picus Security).
2026-10-29 — WordPress publishes GHSA-4w3m-c66w-69mg (rated Low) with backports down to 4.7.39; Wordfence publishes its warning. More than 18,500 malicious requests follow within 21 hours.
2026-10-31 / 11-01 — Wordfence reports 13,095 blocked attacks in 24 hours.
2026-11-03 — CISA adds CVE-2026-119977 to the KEV catalog.
2026-11-04 — BleepingComputer and others report the KEV listing.
2026-11-06 — Remediation due date for US federal civilian agencies.

📚 Resources and References

🤝 SEKurity Supports You

WordPress is rarely the system security teams lose sleep over — it is “just the website”, often run by marketing or an agency. CVE-2026-119977 shows why that view is dangerous: the most routine thing a well-maintained site does, installing its own security update, was enough to hand it to an anonymous attacker. And the domain that gets taken over is the one your customers trust the most.

The useful questions this week are concrete. How many WordPress sites run under your name — including the campaign microsite from three years ago? Who updates them, and when? Can your web servers open connections to arbitrary hosts on the internet? Would anyone notice a new administrator account, or a site that briefly showed an installation screen at 3 a.m.?

We test web applications and the infrastructure behind them from the attacker’s perspective — unauthenticated from the internet, with a low-privileged account, and from a foothold on the web server — and show you how far a compromised website really reaches into your network. If your web presence has never been part of a penetration test, this is the week to change that.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/en/contact

LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your web presence and the servers behind it is our drive.

Sources

WordPress — WordPress 7.1.4 Security Release — release date, 22 fixes, description of the upgrade-window RCE, reporter credit, backports, automatic updates, Gutenberg 24.3
WordPress — GHSA-4w3m-c66w-69mg — “Low” rating, description, publication date, affected and patched versions for every branch from 4.7 to 7.1
Picus Security — CVE-2026-119977: When Updating WordPress Becomes the Vulnerability — root cause (unpack_package(), setup-config.php, update_core()), staging path history, qualifying packages, fix details, first-update gap, nginx/Apache/.htaccess mitigations, manual update guidance
Wordfence — WordPress Core 4.7.0 - 7.1.3 Unauthenticated Upgrade Window Staged Installer RCE — CNA record, CVSS 8.1, affected range
BleepingComputer — CISA flags WordPress RCE flaw as actively exploited in attacks — KEV addition, BOD 26-04 deadline, Wordfence’s 13,095 blocked attacks, wp2shell background
CISA — Known Exploited Vulnerabilities Catalog (CVE-2026-119977) — vulnerability name, date added, due date, required action, ransomware status
Webhosting.Today — CISA lists a fourth WordPress core flaw since July; WordPress rates this one low — rating disagreement, lab-tested window of seconds, firewall blind spot, earlier WordPress core KEV entries, hosting guidance
Daily Security Review — WordPress 7.1.4 Fixes Core RCE Flaw Attackers Are Probing — Wordfence warning on 2026-10-29, 18,500 requests in 21 hours
Barn2 — WordPress market share in 2026 — W3Techs usage share of around 40 percent of all websites
WP-CLI — wp core update, wp user list, wp config get, wp core verify-checksums — command syntax and options used in this article
WordPress Developer Resources — Upgrading WordPress — manual update steps (keep wp-config.php and wp-content)
Apache HTTP Server — mod_alias — RedirectMatch with non-3xx status codes and .htaccess context
EntryZero — Top 5 Hacker-relevant Vulnerabilities (weekly briefing) — weekly vulnerability briefing consulted for topic selection

InSEKurity of the Week (CW45/2026): WordPress Core Upgrade Race Condition RCE (CVE-2026-119977)