11/7/2026

WordPress Upgrade Flaw CVE-2026-119977 Is Being Targeted: What Is Affected and How to Fix It on Each Platform

WordPress の更新中を狙う脆弱性 CVE-2026-119977：悪用の試みが続く、影響範囲と環境別の対処手順

WordPress CVE-2026-119977 abuses a gap during core updates and affects 4.7 through 7.1.3. The US agency CISA has added it to its catalog of known exploited vulnerabilities. WordPress 7.1.4 and branch releases shipped on 28 October with 22 fixes in all. We cover blocking access before you update, steps per platform, notes for Japanese and Chinese packages, and how to check for compromise.

WordPress: Update to 7.1.4 or your branch's fixed release. CVE-2026-119977 is remote code execution through a gap during core updates, and it affects 4.7 through 7.1.3
Exploitation: CISA added it to KEV on 3 November, and Wordfence has blocked more than 240,000 attempts. As of 6 November, we found no public report of a specific compromise
Japanese and Chinese packages: Japanese packages use a complete package even for same-branch updates. The latest official Simplified Chinese build is still 7.1, an affected version
Before updating: Block outside access to wp-content/upgrade/ at the web server and confirm a 403, then update. If you cannot set this up quickly, do not delay the update
After updating: Confirm the version, and check wp-content/upgrade/ for leftovers, your access logs and your administrator accounts

About This Article

This article reflects WordPress announcements, CVE, NVD, CISA, Wordfence and information from each OS and service as of 23:30 Japan time on 6 November 2026. Availability changes over time, so check the latest information through the official links at the end before you start.

Severity figures differ by publisher. We state whose rating each one is.

The blocking rules and commands come from vendor documents and source code, some of them written by us, and none has been tested on a live server. Always confirm the result after applying them.

First: Are You Affected?

Check the Version

In the admin screen, open Dashboard > Updates
With WP-CLI: wp core version --extra
Without WP-CLI: grep "wp_version =" wp-includes/version.php
For many sites on one server (adjust the paths): find /var/www /home -type f -path '*/wp-includes/version.php' -exec grep -H "wp_version =" {} +
To look up WordPress.org's status list (change the version): curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep -E '"7\.1\.3" *:'. insecure means unfixed, outdated means a fixed older branch and latest means the newest release

Fixed Versions

Fixed releases: 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34, 4.7.39
Release date: All on 28 October 2026. The 7.1.4 post says older-branch fixes are in progress, but each branch's version page shows the same date
Target: WordPress actively supports only the latest release. Older-branch fixes are a courtesy, so 7.1.4 is the target
4.6 and older: No security updates. The CVE record starts at 4.7, but Picus says 2.7 through 4.6 share the behavior, so being outside the CVE range does not mean safe

Which Package an Update Uses

CVE and CISA describe updates that use a complete package. The package a site receives depends on its language and the type of update. The results below come from simulated requests to the WordPress update API on 6 November, not from observing real sites.

Sites on the Japanese package: Dashboard and automatic updates are both offered the complete Japanese package, even within a branch
English package with the site set to Japanese: The Dashboard uses the complete Japanese package and automatic updates use the English partial package
English package, same branch: Usually a partial package. It appears not to include the installer, but its contents were not verified. If core files are edited or missing, the Dashboard and WP-CLI move to a larger package
Updates across branches: Usually packages such as no-content. Picus says these are also affected, while the CVE names only complete packages
Chinese sites: The Dashboard is offered the English 7.1.4 package (details below). On 6.8 and older, automatic updates are also offered a complete Chinese package of the branch fix

Do not treat a partial package as safe. Where you can, block access first in every case.

CVE-2026-119977: A Flaw in the Update Window

What Happened

The flaw: During an update, WordPress unpacks new files into a working directory under wp-content/upgrade/. Before the fix, the installer in that directory could be reachable from outside during this time
Impact: An unauthenticated attacker could run code on the server. Before the fix, a wp-config.php created in the working directory was copied over the live wp-config.php, which gave a route to pointing the site at an attacker's database
Conditions (Wordfence): All of these are needed: an update with a package containing the installer, public access to the working directory, a guessed or discovered path, and finishing before cleanup. The window lasted seconds in Wordfence's testing
Guessing the path: In Picus's breakdown, paths on 5.9 through 7.1.3 are predictable, while 4.7 through 5.8 add six random characters, so the path must leak first
Failed updates: If a failed update leaves the working directory behind, it may be attacked with no race at all (Imunify360)
The fix: The working directory name gains 16 random characters, wp-content/upgrade/index.php is kept, and a wp-config.php in the working directory is no longer copied

The update to a fixed release still runs the old updater one last time. Vendors differ on how risky this update is, but Wordfence advises updating soon rather than postponing it.

Why Severity Ratings Differ

Wordfence (CNA): CVSS 3.1 8.1 (High). NVD shows this score too
WordPress: Low, with no CVSS score
Red Hat: Important
CISA SSVC: Exploitation active, automatable no, technical impact total
How to read this: The impact is large if an attack succeeds, but success is difficult, and the ratings weigh these differently. Wordfence says exploitation was very hard in its testing, and Patchstack would not call it practical, while Picus, which reported the flaw, says it built a working exploit chain. Given the CISA listing, however, do not lower the priority of updating

Exploitation Status (as of 6 November)

CISA KEV: Added on 3 November. The deadline for US federal agencies is 6 November. Use in ransomware is listed as unknown
Wordfence telemetry: More than 240,000 attempts blocked from 28 October up to its 5 November post, with a peak of more than 74,000 on 30 October. Most were automated repeat requests, and blocked attempts are not compromises
Actual harm: We found no primary source describing a specific compromise. CISA has not published attack details
Proof-of-concept code: Public GitHub repositories describe themselves as proofs of concept, but they have not been validated. Do not run code you cannot verify
Japan: JPCERT/CC has issued no alert, though its 5 November Weekly Report covers the flaw. We also found no IPA alert, and no public report of victims in Japan

Other Main Fixes

WordPress 7.1.4 fixes 22 issues in all. As of 6 November, CVE-2026-119977 is the only one we could confirm has a CVE.

GHSA-83c2-c4pc-wmp3 (High from WordPress): Stored XSS and denial of service in the Interactivity API. Needs Contributor or above and affects 6.4 and later
GHSA-p2r6-rwjp-phv3 (Medium, Wordfence 5.3): Unauthenticated visitors can see unpublished Customizer changes. Affects 4.9 and later
GHSA-9vrg-x932-q57q (Medium, Wordfence 6.4): Stored XSS in the Customizer. Needs Contributor or above and runs when an administrator opens the preview. Affects 5.0 and later
GHSA-j255-3x8q-7q7g (Medium, Wordfence 6.4): Stored XSS in blocks such as Comments Pagination. Needs Contributor or above and affects 5.9 and later
Others: Fixes also cover the Categories block, the Image and Playlist blocks, Script Modules, Notes, the personal data erasure screen and the multisite users screens
Root certificates: The bundled certificates (composer/ca-bundle 1.6.0) were also updated
Gutenberg plugin: 24.3 and later include the fixes. For 7.2 beta, use Beta 4

Earlier fixes matter too. CVE-2026-87902 was fixed in 7.1.2 and its branch releases (7.0.6, 6.9.9, 6.8.10 and so on down to 4.7.37), and CVE-2026-63030 in 7.0.2 and 6.9.5. Older releases on those branches lack these fixes too. Both are in CISA KEV.

Most Exposed Setups

Sites on the Japanese package with automatic updates: Unattended updates use a complete package as well
Sites that cannot block at the web server: A firewall running inside WordPress cannot stop this, because the staged copy does not load the site's plugins (Patchstack). Wordfence's own firewall needs Extended Protection for this, and its rule reaches the Free tier only on 27 November
Sites left after a failed update: The working directory may still be there
Sites with automatic updates stopped: The fix never arrives and they stay on the old version
Sites with several authors: Most of the other 21 issues need a Contributor account or above

Fix, Step 1: Block Outside Access Before Updating

Wordfence's author recommends this block for operators who can apply it quickly, but warns others not to delay updating to work out how. The block is temporary and does not fix the other 21 issues.

nginx: Add location ^~ /wp-content/upgrade/ { return 403; } to the server block, then run nginx -t and nginx -s reload
Apache virtual host: Add these three lines (adjust the path)
<Directory "/var/www/html/wp-content/upgrade">
Require all denied
</Directory>
Applying the Apache change: Run apachectl configtest, then apachectl -k graceful
.htaccess on shared hosting: In the .htaccess file in the WordPress folder, add these two lines above # BEGIN WordPress
RewriteEngine On
RewriteRule ^wp-content/upgrade/ - [F]
OpenLiteSpeed: Use the RewriteRule form above, enable automatic loading of .htaccess and restart
Caddy: Add respond /wp-content/upgrade/* 403 to the site block, then run sudo systemctl reload caddy
IIS: Add <add sequence="/wp-content/upgrade/" /> to <denyUrlSequences> in web.config. The response is 404 rather than 403, logged as 404.5
Bitnami VMs: .htaccess may have no effect. Add the <Directory> form above to /opt/bitnami/apache/conf/vhosts/htaccess/wordpress-htaccess.conf with the path /opt/bitnami/wordpress/wp-content/upgrade, then run sudo /opt/bitnami/ctlscript.sh restart apache

Paths: Sites in a subdirectory must add that prefix to the nginx and Caddy rules. The working directory sits under WP_CONTENT_DIR, so on Bedrock it is /app/upgrade/
Do not place files inside the folder: An .htaccess or index.php inside wp-content/upgrade/ does not help, because the unfixed updater deletes it
Confirm: Run curl -I https://example.com/wp-content/upgrade/probe.php and expect 403. An Apache <Directory> rule may return 404 if the folder does not exist, and that result proves nothing. A <Directory> rule also does not apply where ProxyPassMatch sends PHP to PHP-FPM. In that setup, use <Location "/wp-content/upgrade/">, Require all denied and </Location>, adding any subdirectory prefix

Fix, Step 2: Update

Back up files and the database
Apply the block above and confirm the result
Update. In the admin screen use Dashboard > Updates. With WP-CLI, use wp core update --minor to stay on your branch, or wp core update for the latest release followed by wp core update-db (wp core update-db --network on multisite)
Confirm the version

WP-CLI notes: --version and --locale force a complete package. Do not use --force, which can downgrade a newer install
Database: A same-branch update needs no database step
Manual update: The official steps are to back up, deactivate plugins, unpack the package, delete old files while keeping wp-config.php, wp-content and similar, upload the new files and visit /wp-admin/
Minimum PHP: 7.1.4 and 7.0.8 need PHP 7.4, branches 6.6 to 6.9 need 7.2.24, 6.3 to 6.5 need 7.0, 5.2 to 6.2 need 5.6.20, and 4.7 to 5.1 need 5.2.4
4.6 and older: We recommend replacing files by hand with a supported release rather than using the old updater
PHP itself: Updating WordPress does not fix PHP. See this article for the October PHP fixes

Sites Where Automatic Updates Do Not Arrive

The 7.1.4 post says sites that support background updates will update automatically, but it does not mention forced updates. Always check.

Open Tools > Site Health in the admin screen and read the background updates result
Check your settings: grep -nE "DISALLOW_FILE_MODS|AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISABLE_WP_CRON" wp-config.php
If .git, .svn, .hg or .bzr exists in the WordPress folder or a parent folder, automatic updates stop
Check for a recorded failure: wp option get auto_core_update_failed --format=json (on multisite, wp site option get auto_core_update_failed --format=json)
Sites with DISABLE_WP_CRON set and no system cron do not run automatic updates

Notes for Chinese Packages

New installs: https://cn.wordpress.org/latest-zh_CN.zip is 7.1, an affected version. Do not use it for a public site. Start from https://downloads.wordpress.org/release/wordpress-7.1.4.zip and choose Chinese as the site language (our suggestion)
Existing sites: After blocking, update from Dashboard > Updates. As of 6 November, the API offers the English 7.1.4 package
Versions with no build: There is no Simplified Chinese build for 7.1.1 and later, 7.0.5 and later, or 6.9.8 and later. Builds exist for 6.8.12 and earlier
WP-CLI: Use wp core update --minor or wp core update, without --version=7.1.4
Checksums: Where no Simplified Chinese list exists, use wp core verify-checksums --locale=en_US. Leftover Chinese files may show mismatches
Traditional Chinese: The newest build is 7.0.8, and there is no 7.1 branch. However, https://tw.wordpress.org/latest-zh_TW.zip still serves 7.0.4, an affected version, so do not use it

Fixed Versions and Steps per OS and Environment

Debian 13: 6.8.12+dfsg1-0+deb13u1 (DSA-6596-1). Run sudo apt update and sudo apt install --only-upgrade wordpress, then confirm with dpkg-query -W wordpress
Debian forky and sid: 7.1.4+dfsg1-1
Debian 12: 6.1.9+dfsg1-0+deb12u1 is unfixed as of 6 November. We suggest moving to Debian 13 or to a fixed upstream release. Debian 11 and older are also unfixed
Ubuntu: The archive's wordpress is jammy 5.8.3, noble 6.4.3 and resolute 6.7.2, and we found no fixed version. Ubuntu's CVE page could not be read, so its status is unconfirmed. Check with apt-cache policy wordpress, and for public sites we suggest moving to a fixed upstream release
Fedora: Fedora Rawhide (fc46) and Fedora 45 have 7.1.4-1 in stable. 6.9.11-1 for Fedora 44 and 43 is still in testing as of 6 November. If sudo dnf upgrade --refresh wordpress brings nothing, add --enablerepo=updates-testing
RHEL family (EPEL): Red Hat does not ship WordPress. EPEL fixes are in testing as of 6 November. Update with sudo dnf upgrade --refresh --enablerepo=epel-testing wordpress
Arch Linux: wordpress 7.1.4-1. Run sudo pacman -Syu
Gentoo: www-apps/wordpress offers 7.1.4, 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14 and 6.4.14, all with testing keywords
FreeBSD: www/wordpress is 7.1.4 on main, but the 2026Q4 quarterly branch is 7.1.2 and unfixed. VuXML has no WordPress entry, so pkg audit will not flag it
Official Docker image: wordpress:7.1.4 and wordpress:latest are fixed. Changing the image does not update an existing volume, so check with docker exec <container> grep wp_version wp-includes/version.php and update inside the site. wordpress:7.0, wordpress:6.9 and wordpress:6.8 are no longer updated and remain vulnerable
Bitnami container: bitnami/wordpress:latest is 7.1.4 on Photon. The Helm chart default is an old version, so set the image explicitly. bitnamilegacy/wordpress is no longer updated
Composer and Bedrock: roots/wordpress has 7.1.4. Bedrock turns off automatic updates by default, so run composer require roots/wordpress -W, check that composer.lock shows 7.1.4 or later, and deploy
1Panel: The app moved to 7.1.4, but a site on its volume may not have changed. In the app folder, check grep "wp_version =" data/wp-includes/version.php, and update inside the site if it is old
Softaculous: The list still includes older unfixed versions. Choose only fixed releases for new installs
WP Toolkit (cPanel, Plesk): Check each site's version and automatic update setting
AWS Lightsail: Updating existing instances is the customer's job. Take a snapshot, block access, then update. From 19 November, the Bitnami WordPress blueprint can no longer be chosen for new instances
Azure App Service: Minor auto-updates are on by default, but confirm the version in wp-admin
Pantheon: The fix is available, but it reaches Live only after you run Apply Updates on the dashboard's Code tab and deploy through Test and Live
WP Engine: Its general policy is to apply security releases early, but we found no statement on 7.1.4
Kinsta and WordPress.com: We found no statement on this round. Check the version and contact the provider if it is not fixed
Windows and macOS: There is no official server package. brew upgrade wp-cli updates the CLI only, not your site's WordPress

Japanese Shared Hosting

ConoHa WING: Posted a notice on 29 October and updated it on 30 October. New installs get 7.1.4. Existing sites update in sequence if auto-update is on, and otherwise need a manual update. The notice's line about no exploitation reports predates the CISA listing
Onamae.com Rental Server: Posted a notice on 29 October. Existing sites update in sequence if auto-update is on, and otherwise need a manual update. Its line about no exploitation reports also predates the CISA listing
Lolipop!: The news list read on 6 November ends at 24 October, before this release, so it shows nothing about this round
Xserver, Shin Rental Server, Star Server, Sakura Rental Server, mixhost and KAGOYA: We saw no notice on this round in the news lists read on 6 November. The lists cover different periods, and we could not confirm whether server-side measures exist

Do not assume your provider has handled this. Check the version in Dashboard > Updates.

What to Check After Updating

Version: Compare each site with the fixed list, even if automatic updates are on
Whether the fix is in place: grep -n get_working_dir_name wp-admin/includes/class-wp-upgrader.php prints a line on the fixed updater
PHP cache: With opcache.validate_timestamps=0, reload PHP-FPM or Apache after updating by WP-CLI, package or hand. php -i on the command line may differ from the web settings
Leftover files: Run find wp-content/upgrade -name "*.php" | sort. A clean fixed site shows only index.php or nothing. Investigate wp-config.php or any other PHP file
Cleaning up: Confirm no update is running (core_updater.lock and auto_updater.lock are not set), then delete everything except index.php. Leave wp-content/upgrade-temp-backup/ alone
Access logs: Search for requests to PHP in the working directory with a command such as grep -E 'wp-content/upgrade/.*\.php' /var/log/nginx/access.log*. Adjust the path and use zgrep for compressed logs. Your own probe.php test from the block check will also appear. A clean log does not prove a site is safe
Administrators: Check for unknown accounts with wp user list --role=administrator --format=csv
Plugins: Check for unknown plugins and tampering with wp plugin list and wp plugin verify-checksums --all
Core files: Run wp core verify-checksums --include-root (WP-CLI 2.8.0 or later). This does not cover plugins or uploads
Database target: Run grep -nE "DB_(NAME|USER|HOST)" wp-config.php and confirm it shows your own database. This command does not print the password
If you suspect compromise: Isolate the site and preserve logs. Restore from a trusted backup, and change database, administrator and API credentials and the wp-config.php keys

Official Sources

Disclaimer

This article was compiled by Two Sheep Co., Ltd. from public information available on 6 November 2026 and does not guarantee the behavior or safety of any product. Always check the latest information from each provider before you start. Company and product names are trademarks or registered trademarks of their respective owners. Companies are named as sources or subjects of information, and their mention does not indicate any business relationship with Two Sheep.

If you need on-site work at a data center, such as a server restart, console work or equipment replacement, please contact us about our Remote Hands service.