WordPress's October 2026 Upgrade RCE and Stored XSS Fixes: WordPress 7.1.4

#Overview

WordPress released 7.1.4 on October 28 as a security release. Its HelpHub page lists 17 entries covering 22 vulnerabilities in WordPress core. The headline one is a race condition in the core updater "that could lead to remote code execution." Most of the rest are stored cross-site scripting (XSS) in blocks, the Customizer, and the Interactivity API. The others expose unpublished Customizer changes to logged-out visitors, let saved content hang a visitor's browser, and give some custom roles access to notes. Backports for every older branch followed the same day, from 7.0.8 down to 4.7.39, though WordPress.org's update service wasn't offering the ones for 6.5 and older as of 4:55 PM CDT, October 28. WordPress hasn't rated any of the issues, and none has a CVE ID. We rate the release High overall (ratings). WordPress's announcement: "Because this is a security release, it is recommended that you update your sites immediately."

Why it's urgent: WordPress runs 39.5% of all websites, per W3Techs. Attackers have moved fast on WordPress core fixes this year. CISA has added three core CVEs to its Known Exploited Vulnerabilities (KEV) catalog since July, most recently CVE-2026-87902, fixed in 7.1.2 on September 22. Patchstack saw the first attempts against that one the same day, and concluded that "whoever built them was working from the diff rather than from an independent discovery." This release's fixes have been public in WordPress's GitHub mirror since 8:26 AM CDT today. Patchstack, for its part, gives every one of its entries for this release a "Low" priority and calls the updater race "impractical to exploit in practice." See the timeline.

#Key facts

#Who is affected

Every site running a WordPress version below its branch's fixed release. HelpHub gives the count per branch:

Only 7.1 is supported. WordPress says older branches get fixes "as a courtesy," and branches 4.7 – 6.8 got theirs today, 4.7.39 through 6.8.12, at two speeds:

• 6.6 through 6.8 shipped by 11:32 AM CDT, and WordPress.org's update service offers them.
• 6.5 back to 4.7 shipped between 3:43 and 4:51 PM CDT, one release every few minutes. As of 4:55 PM CDT, October 28, the update service still offers the previous releases on those branches, so background updates and the dashboard won't install them yet. The packages are on the release archive.

By WordPress.org's version statistics, 64.3% of sites run 7.1, 22.7% run 7.0 through 6.6, and 12.0% run 4.7 through 6.5. So 99.1% have a fixed release on their branch, though the update service isn't offering it to that last 12.0% yet. The other 0.9% run 4.6 or older, which gets nothing.

#Hosting platforms

Managed hosts handle this differently, so check your host's notice rather than assuming the update is automatic:

• WordPress VIP: "WordPress 7.1.4 has been rolled out to all WordPress VIP environments running WordPress 7.1. The security patches have also been backported to sites running older WordPress versions."
• Pantheon marks its notice "Action required": customers apply the update from the dashboard or Terminus. In the meantime, "Pantheon has deployed platform-wide mitigations against external abuse of some of the vulnerabilities fixed in this release."

#Builds outside the table

• The Gutenberg plugin. The block fixes and the Interactivity API's script fixes come from Gutenberg, the block-editor project, through a pinned commit in core that brings in five fix commits. Gutenberg 24.3.0, released at 11:36 AM CDT, carries the same five commits, though its release notes don't mention security. In our reading, the plugin loads its own copies of the blocks and the Interactivity API's scripts in place of core's. So a site that runs the plugin needs 24.3.0 as well as the core update. We haven't tested older plugin versions against these fixes.

• The official Docker image has had 7.1.4 on most of its tags since this afternoon, though for most sites the image version matters less than you'd expect (details).

• Composer installs. On Packagist, roots/wordpress-no-content has had 7.1.4 since 12:15 PM CDT, and johnpbloch/wordpress since 2:49 PM. Sites deployed this way usually set DISALLOW_FILE_MODS, which turns off background updates. They change only when someone bumps the package and deploys.

• Distribution packages haven't moved. As of 4:55 PM CDT, October 28:

  • Debian: sid and forky have 7.1.3, trixie 6.8.7 (with 6.8.10 in proposed-updates), and bookworm 6.1.9.
  • Ubuntu: the universe packages are still at their release versions: 6.4.3 in noble, 6.7.2 in resolute.
  • Fedora: Fedora 43, Fedora 44, EPEL 9, and EPEL 10 have 6.9.10; ELN has 7.1.3.

  Distribution security trackers key on CVE IDs, which this release doesn't have yet.

#How the vulnerabilities work

The updater race. When WordPress installs a core update, it unpacks the new release into a working directory under wp-content/upgrade/, then copies the files into place. That directory sits inside the site, where a web server can serve it. WordPress calls the flaw "a race condition during core updates that could lead to remote code execution." Patchstack lists it as needing no account. An attacker has to act in the seconds an update is running, which is why Patchstack calls it "impractical to exploit in practice."

Stored XSS. Most of the remaining entries. Someone with an account saves content (a post, a block, a username) that WordPress later outputs without neutralizing the script in it. The script runs in the browser of whoever views the content. Most of these need the Contributor role, the lowest role that can write posts. If an administrator views the content, the script runs with that administrator's session, and on most sites an administrator can install plugins.

The rest:

• Unpublished Customizer changes. The Customizer saves design changes as drafts, called changesets, before they're published. Logged-out visitors could see the most recent unpublished one.
• A stored denial of service. A Contributor could save content that makes the page unresponsive in a visitor's browser. Patchstack notes that the server isn't affected.
• Notes. Custom roles that can moderate comments could read, edit, and delete notes (editorial comments in the block editor) on posts they can't edit. Patchstack says the default roles aren't affected.

The block fixes and the Interactivity API's script fixes come from Gutenberg. You get them by updating WordPress, and by updating the Gutenberg plugin too if you run it (details).

#The fix

The fixes landed in trunk between 8:26 and 8:40 AM CDT on October 28, and were merged to the 7.1 branch between 9:49 and 10:03 AM. The root-certificate update had gone in three days earlier.

• The updater fix is titled "Improve the handling of the upgrade working directory." It changes how WordPress creates and protects that working directory, and puts an index.php in wp-content/upgrade/ so that a server with directory listing on can't list it.
• The Interactivity API fix is the largest. It limits what bindings can change on object elements and adds 101 lines to kses.php, WordPress's HTML filter.
• The Gutenberg pin carries five fixes, which its commit message lists as:
  • "Interactivity API: Harden directive processing and client-side navigation"
  • "Block parser: Only accept HTML whitespace in block delimiters"
  • "Categories block: Don't run the dropdown label through sprintf()"
  • "Use the HTML API to insert the Image lightbox button and the Playlist waveform player"
  • "Escape the labels of the post navigation and comments pagination links"
• The root certificates move to composer/ca-bundle 1.6.0, which "adds four and removes five certificates to the bundle."

Each older branch gets a single backport commit (sizes).

#Vulnerabilities by severity

WordPress hasn't rated these, so the ratings here are Atlas's. They weigh who can reach each bug, what it gets them, and whether anyone is exploiting it. They aren't CVSS scores; Patchstack's scores are shown beside them. If WordPress publishes its own ratings, we'll add them here.

WordPress counts 22 vulnerabilities but describes them in 17 entries, so the list has 17. Titles are HelpHub's. The access each needs comes from HelpHub's titles where they give one ("Contributor+"), and from Patchstack's entries otherwise.

Overall: High. The worst issue is remote code execution that needs no account. We don't rate it Critical because it works only during the seconds an update runs, and Patchstack calls it impractical to exploit. The count doesn't raise the rating: 21 issues that mostly need an account don't add up to one that doesn't.

#High

1. "A race condition during core updates that could lead to remote code execution." No account needed · Patchstack CVSS 9 · Umut Bayram

#Medium

Stored script that runs when an editor or administrator opens the content, or, for the Customizer, data anyone can read. Each needs an account you've granted, except the Customizer issue.

2. "An information disclosure issue exposing unpublished Customizer changes to unauthenticated visitors." No account needed · Patchstack 5.3 · Antonio Lorensius Silaban
3. "A Contributor+ stored cross-site scripting (XSS) issue via whitespace in block delimiters." Contributor · Patchstack 5.4 · Rafie Muhammad, Awesome Motive
4. "A Contributor+ stored cross-site scripting (XSS) issue in Customizer selective refresh." Contributor · Patchstack 6.5 · Rafie Muhammad, Awesome Motive
5. "A Contributor+ stored cross-site scripting (XSS) issue in the labels of the Comments Pagination and Post Navigation Link blocks." Contributor · no Patchstack entry · Alex Concha
6. "A cross-site scripting (XSS) issue in the Categories block via format string injection." Contributor · Patchstack 5.4 · Ben Bidner
7. "An issue allowing post content to shadow Script Module data with a matching element ID." Contributor · Patchstack 7.4, as XSS · Weston Ruter
8. "A Contributor+ stored cross-site scripting (XSS) issue via javascript: URLs in Interactivity API bindings." Contributor · Patchstack 6.5 · Luis Herranz and others
9. "A Contributor+ stored cross-site scripting (XSS) issue via Interactivity API event handler bindings." Contributor · Patchstack 7.4 · Jon Surrell
10. "A Contributor+ stored cross-site scripting (XSS) issue via prototype pollution in Interactivity API context namespaces." Contributor · Patchstack 7.4 · rekter0
11. "Contributor+ stored cross-site scripting (XSS) and denial of service issues in Interactivity API bindings." Contributor · Patchstack 7.4 (XSS) and 5 (DoS) · rekter0, Marcel Karlsson, Jon Surrell, Alex Concha
12. "An Author+ stored cross-site scripting (XSS) issue in the Interactivity Router via uploaded text files." Author · Patchstack 6.5 · Anas cherni
13. "A hardening fix for unsafe preg_replace() replacements in the Image and Playlist blocks." Author · Patchstack 7.4, as XSS · Ben Bidner. WordPress calls it hardening; we rate it on Patchstack's description.

#Low

Each needs an unusual setup or a role that's already trusted.

14. "A hardening fix for unescaped usernames on the multisite Network Users screens." Subscriber, but only with a username stored by other code, per Patchstack · Patchstack 5.4 · Anthropic
15. "A Contributor+ issue in Interactivity API bindings that lets object elements load admin pages." Contributor · Patchstack 5 · rekter0. WordPress and Patchstack class it as an access-control issue, not XSS.
16. "An Editor+ stored cross-site scripting (XSS) issue in the personal data erasure requests screen." Editor · Patchstack 6.5 · Anthropic. On a single site, editors can already publish unfiltered HTML, so this matters mostly on multisite, where they can't.
17. "A permissions issue letting custom roles that moderate comments read, edit and delete notes on posts they can't edit." A custom role · Patchstack 3.8 · Ramon. The default roles aren't affected, per Patchstack.

#Which sites are exposed

What follows is our reading of WordPress's and Patchstack's entries. It describes exposure, not confirmed exploit paths. The ratings give the access each issue needs.

The updater race needs two things.

• The site updates itself in place, whether through background updates, the dashboard, or WP-CLI. Sites deployed from git or Composer with DISALLOW_FILE_MODS set don't.
• The web server serves wp-content/upgrade/. Directory listing makes it worse, which is why Patchstack's advice includes making sure the directory "is not listable":
  • stock Debian and Ubuntu Apache configs turn listing on for /var/www (Options Indexes FollowSymLinks);
  • the official Docker image turns it off (Options -Indexes);
  • nginx's autoindex is off by default.

The update to 7.1.4 is the last update the old code unpacks. In our test, 7.1.3 updating itself to 7.1.4 left wp-content/upgrade/ without the new index.php, which appeared only on the next unpack. So the window opens once more on the way to the fix. Block the directory first (how).

The account-based issues matter where people you don't fully trust hold Contributor or above. Examples: multi-author sites and newsrooms, agencies' client logins, and membership or course plugins that hand out writing roles. WordPress's default role for new users is Subscriber. Per Patchstack, that reaches only the username hardening issue, and only with a username stored by other code.

Patch these first: sites with outside contributors, multisite networks, and sites that update in place with a listable wp-content/upgrade/.

#How to check your systems

Check every WordPress you run: production, staging, the campaign site on another host, and the ones in containers. A dashboard shows one site at a time. We tested these commands against the official wordpress:7.1.3-apache image, updated in place to 7.1.4, with WP-CLI 2.12.0 and GNU grep 3.8, and the nginx rule with nginx 1.31.4.

#Check a site's version

With WP-CLI:

1wp core version

It prints 7.1.4, or your branch's fixed release once you're patched. Without WP-CLI, read the version file from the site's root:

1grep -m1 '^\$wp_version' wp-includes/version.php

From outside, many sites still print their version in the feed:

1curl -s https://example.com/feed/ | grep -o '<generator>[^<]*</generator>'

That prints <generator>https://wordpress.org/?v=7.1.4</generator>. Plenty of sites strip it, so no output proves nothing.

After updating, wp core verify-checksums confirms the core files match the release. On the official Docker image it also warns File should not exist: wp-config-docker.php. That file is the image's own, and the warning is expected.

#Check background updates

WordPress installs security releases on its own unless something turns that off. Look for the usual switches:

1grep -nE 'WP_AUTO_UPDATE_CORE|AUTOMATIC_UPDATER_DISABLED' wp-config.php2grep -nE 'DISALLOW_FILE_MODS|DISABLE_WP_CRON' wp-config.php

No output means the defaults, and security releases install automatically. These settings turn that off:

• WP_AUTO_UPDATE_CORE set to false;
• AUTOMATIC_UPDATER_DISABLED or DISALLOW_FILE_MODS set to true;
• a .git or .svn directory in the install, which WordPress treats as a version-controlled checkout.

These constants can also come from elsewhere, such as the Docker image's WORDPRESS_CONFIG_EXTRA.

WordPress checks for updates twice a day through WP-Cron, which runs only when the site gets traffic:

1wp cron event list --fields=hook,next_run_relative | grep wp_version_check

That shows the next check, e.g. 58 minutes 3 seconds. If DISABLE_WP_CRON is set, a system cron job has to call wp-cron.php, or the check never runs.

#Check the upgrade directory

1curl -s https://example.com/wp-content/upgrade/ | grep -c 'Index of'

A count above 0 means the server lists the directory. The status code alone doesn't tell you. On our test site, a missing upgrade/ directory returned a WordPress page with a 200, and after 7.1.4 the directory holds a blank index.php that also returns 200. Once you've added a deny rule, this should print 403:

1curl -s -o /dev/null -w '%{http_code}\n' https://example.com/wp-content/upgrade/

For a site in a subdirectory, add it to the path.

#Check images and running containers

docker-library/wordpress moved to 7.1.4 at 1:46 PM CDT, and the pull request publishing it merged at 3:50 PM. Docker Hub's tags then moved one at a time. As of 4:55 PM CDT, October 28, latest, 7.1, and 7.1.4 held 7.1.4, but the amd64 image behind 7 was still 7.1.3, per the images' build history.

On most container setups, the image tag doesn't tell you what the site runs. The official image's entrypoint copies WordPress into /var/www/html only when neither index.php nor wp-includes/version.php is there. On a persistent volume, a new image changes nothing: the site updates itself, or doesn't. In our test, a container still on the 7.1.3-apache image ran 7.1.4 after an in-place update and a restart. Check the running files instead:

1for c in $(docker ps -q); do2  v=$(docker exec "$c" sh -c \3    'grep -s -m1 "^\$wp_version" /var/www/html/wp-includes/version.php' \4    2>/dev/null)5  [ -n "$v" ] && echo "$(docker inspect -f '{{.Name}}' "$c") $v"6done

It prints one line per WordPress container, such as /blog $wp_version = '7.1.4';. Containers without a shell are skipped. For images that put WordPress somewhere else, change the path. Images that bake WordPress in, instead of using a volume, need a rebuild on a 7.1.4 base.

#Check accounts and plugins

For the account-based issues, list who can write:

1wp user list --role__in=contributor,author,editor --fields=user_login,roles2wp option get users_can_register3wp option get default_role

users_can_register is 0 when registration is closed. default_role should be subscriber. If the Gutenberg plugin is installed, check that the Plugins screen shows 24.3.0.

#How to fix

#Update WordPress

1. Block wp-content/upgrade/ first (rules). The old code unpacks the update to 7.1.4.

2. Update:

   • From the dashboard: Updates, then Update Now.
   • With WP-CLI, wp core update --minor stays on your branch; it took our test site from 7.1.3 to 7.1.4.
   • Plain wp core update moves to the latest release.

   Aim for 7.1.4: "only the most recent version of WordPress is actively supported," and 7.2 is planned for December 8. On a multisite network, one update covers every site.

3. Update the Gutenberg plugin to 24.3.0 if you run it.

4. Confirm: wp core version and wp core verify-checksums.

The rest depends on how the site is deployed:

• Containers on a volume: update in place.
• Images with WordPress baked in: rebuild on wordpress:7.1.4, or 7.1, which has it too.
• Composer: bump roots/wordpress (or johnpbloch/wordpress) to 7.1.4 and deploy.
• Sites on 6.5 or older: until WordPress.org's update service offers your branch's release, the dashboard won't show it. Install the package from the release archive, or move to 7.1.4, which the dashboard does offer.

This release is separate from last week's PHP fixes. WordPress said of those that "No WordPress update is required or planned for these issues," so a site that took 7.1.4 still needs patched PHP, and the reverse. Our PHP post has the fixed versions.

#If you can't patch immediately

We found no government or CERT advisory for this release as of 4:55 PM CDT, October 28. For the updater race, Patchstack says no firewall rule of its own can cover it, and advises: "Deny web access to wp-content/upgrade/ at the web server instead and make sure that directory is not listable." Pantheon says it has "deployed platform-wide mitigations against external abuse of some of the vulnerabilities fixed in this release," without saying which.

We tested both of the following rules on the setups named above.

Apache: put this in the site's root .htaccess, above # BEGIN WordPress, or in the server config:

1RedirectMatch 403 /wp-content/upgrade/

WordPress rewrites only the lines between its own markers, and the rule survived wp rewrite flush --hard. Don't put it in a .htaccess inside wp-content/upgrade/. The updater empties that directory before each unpack, and in our test it deleted the file.

nginx: add this to the site's server block:

1location ^~ /wp-content/upgrade/ {2    deny all;3}

The ^~ matters. Without it, the usual location ~ \.php$ block still handles PHP files under the directory. In our test, a plain prefix location returned 403 for the directory and 200 for a PHP file inside it.

Atlas's interim recommendations:

• Review the accounts that can write. Remove those nobody needs, and confirm default_role is subscriber.
• Leave background updates on. Turning them off to control timing keeps the site on old code longer.

#End-of-life versions

WordPress's policy, restated when it ended updates for 4.1–4.6 in July 2025: "As a reminder, the only actively supported version of WordPress is the most recent one. Security updates are only backported to older branches as a courtesy." HelpHub says "WordPress 4.6 and earlier no longer receive security updates." That's 0.9% of sites by WordPress.org's statistics. The vulnerabilities HelpHub counts against them aren't stated.

Each older branch gets one backport commit carrying only the fixes that apply to its code, so the commits shrink with age:

WordPress hasn't announced the next cutoff. The last one dropped 4.1–4.6 when, in its words, "over 99% of WordPress installations run a more recent version." Today 4.7 through 4.9 hold 1.6% of sites. Every branch below 7.1 trails the supported release. Moving to 7.1 is the only way onto code WordPress actively maintains.

#Timeline

All times are CDT (UTC−5).

#Updates to this post

We'll revise this post when:

• WordPress.org's update service starts offering the releases for 6.5 and older;
• WordPress publishes GitHub advisories with its own severities, which we'll show beside ours;
• CVE IDs appear;
• the distributions ship 7.1.4;
• exploitation is reported, or an issue reaches the KEV catalog;
• Patchstack or another database changes a rating.

#Get help

If you'd rather not work through this alone, our advisors can help with the site inventory, the update and the web-server rules, or a review of who holds which role.

Our free external audit checks the domains and public IPs you verify for open services, publicly visible software versions with known CVEs, TLS, email security, DNS, and HTTP headers. A WordPress site that prints its version in its feed or a generator tag shows up there as a publicly visible software version.

PHP's own critical fixes landed a week earlier, and WordPress sites need them separately: see PHP's October 2026 Critical RCEs.

#Sources

WordPress

• WordPress 7.1.4 (announcement)
• Version 7.1.4 (HelpHub: entries, per-branch counts, files)
• Critical PHP Security Release, October 21
• Dropping security updates for WordPress versions 4.1 through 4.6, June 2025
• WordPress version statistics
• Release archive

Code

• wordpress-develop 7.1.3…7.1.4
• wordpress-develop security advisories
• Gutenberg pin, dd294ab…8daba42
• Gutenberg 24.3.0

Advisories and databases

• Patchstack: WordPress core vulnerabilities, including the updater race entry
• CVE-2026-87902 and GHSA-7hp8-65ch-5whp (7.1.2)
• CISA Known Exploited Vulnerabilities catalog
• CVE Numbering Authorities list

Hosting platforms

• WordPress VIP: WordPress 7.1.4 Security Release
• Pantheon: WordPress 7.1.4 Security Release now available

Distributions and packages

• Debian: wordpress
• Ubuntu: wordpress
• Fedora: wordpress updates
• Packagist: roots/wordpress-no-content, johnpbloch/wordpress

Containers

• docker-library/wordpress, including the entrypoint
• official-images pull request #22617

Research and reporting

• Patchstack: CVE-2026-87902: Attackers Started Probing WordPress Sites Hours After the Patch
• W3Techs: WordPress usage statistics