Published October 23, 2026. Based on public CVE records available on that date; details may change.

CVE-2026-114570 is a stored cross-site scripting (XSS) flaw in WordPress core's Quick Edit screen, caused by insufficient escaping of user display names. The CVE record lists WordPress up to and including 7.0.2 as affected, and the fix shipped in the WordPress 7.0.3 security release on August 6, 2026. Most sites received it through automatic minor updates, but you should confirm your version today, because the current releases are 7.1.3 and 7.0.7.

What happened

The vulnerability lets a logged-in user with Contributor access or higher store script in a user display name that WordPress later prints on an administrative screen without enough escaping. According to the CVE record, the script runs when a higher-privileged user, such as an editor or administrator, opens the affected admin screen.

In plain terms, stored XSS means the attacker saves the payload once and waits for someone else to load it. When the person who loads it is an administrator, the script runs with that administrator's browser session. That is why low-privilege XSS in the admin area is worth patching even when the attacker starts with a modest role.

The record adds an important limit: the issue only affects sites with a large number of users. Neither the record nor the WordPress release post states the exact threshold, so we will not guess one here.

The WordPress 7.0.3 release post lists the issue as "Contributor+ stored cross-site scripting (XSS) in Quick Edit on sites with a large number of users," one of several security fixes in that release. The CVE record was published on October 22, 2026, well after the fix itself shipped.

Severity and exploitation status

The CVE record, assigned by Wordfence, gives a CVSS 3.1 base score of 4.9 (Medium). The vector shows network access, high attack complexity, low privileges required (a Contributor account), no separate user interaction in the scoring, and a changed scope with low confidentiality and integrity impact.

The record's CISA enrichment lists exploitation as "none" and the issue as not automatable. The records reviewed for this article do not mention exploitation in the wild.

Who is affected

The record lists every WordPress branch from 4.7 through 7.0 as affected, with a last affected release per branch. For example, it lists 7.0.0 through 7.0.2, 6.9.0 through 6.9.5, 6.8.0 through 6.8.6, and 4.7.0 through 4.7.33. The 7.1 branch is not listed as affected, and the release post says WordPress 7.1 RC2 already contained the fixes.

The release post also says the fixes were backported, as a courtesy, to all branches still eligible for security fixes (currently back to 4.7). Only the most recent version of WordPress is actively supported. As of October 23, 2026, WordPress.org offers 7.1.3 as the latest release and 7.0.7 as the current 7.0 release, and older branches have their own later security releases.

Risk depends on how your site uses accounts. Sites with many registered users and several people at Contributor level or above match the conditions in the record most closely. A small brochure site with one administrator and no other accounts has less exposure, but it should still run a current version.

How to check your WordPress version

You can confirm the installed version from the dashboard or from the command line.

  1. In the WordPress admin, open Dashboard > Updates. The page states which version you run and whether a newer one is available.
  2. If you use WP-CLI, run wp core version from the WordPress directory. It prints the installed version number.
  3. Run wp core check-update to see whether WordPress.org offers a newer release for your site.
  4. If you manage several sites, record the version for each one, including staging copies.

If the version is 7.1.3, or 7.0.7 on the 7.0 branch, you are on the current release for that branch. If you see 7.0.2 or older on the 7.0 branch, the site is missing this fix and the later 7.0 security releases.

Why automatic updates usually cover this

WordPress installs minor and security core releases automatically by default, so most sites moved past 7.0.2 without anyone clicking a button. Automatic updates can still be switched off. Common causes are AUTOMATIC_UPDATER_DISABLED or WP_AUTO_UPDATE_CORE set to false in wp-config.php, a host that manages updates on its own schedule, a plugin that disables updates, or file permissions that block WordPress from writing its own files.

If Dashboard > Updates shows an older version than you expected, look for one of those causes before updating, so the next security release does not stall the same way. Our WordPress maintenance plan checklist covers how to track core, plugin, and theme updates across sites.

What to do now

The main step is to run the current release for your branch. Use Dashboard > Updates and click Update Now, or run wp core update --minor with WP-CLI to apply the latest minor release in your current branch. Moving to 7.1.3 is also an option when your theme and plugins support it.

After updating, review who can reach the vulnerable path:

  • Open Users and filter by role. Remove Contributor, Author, and Editor accounts that are no longer needed.
  • Check display names for unusual characters or markup. A display name should read like a name, not like code.
  • Confirm every administrator account belongs to a known person. Our guide to finding hidden WordPress admin users walks through that check.
  • Run wp core verify-checksums to confirm core files match the official release. It does not check plugins, themes, or the database.

Updating removes the flaw, but it does not undo anything an attacker did before the update. If a site with many contributors ran an affected version for months, a short review of users and recent admin activity is reasonable. Limiting roles and accounts is part of our WordPress hardening checklist.

When to get help

Get help if you cannot update core, if updates keep failing, or if you find accounts or admin changes nobody on your team can explain. A security audit can review update settings, user roles, and access controls, while WordPress malware removal is the right starting point if you suspect the site was already compromised.

Sources