On 28 October 2026 WordPress released 7.1.4, a security release that fixes multiple issues. One of them is a weakness in the WordPress upgrade process which can lead to remote code execution during the upgrade window. On 3 November the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog, a list reserved for flaws with evidence of active exploitation.
If your business website runs on WordPress, this is the update to confirm this week. Here is what the flaw is, who it affects, how to check your version, and what to ask whoever looks after your site.
What it is, in plain terms
The flaw is tracked as CVE-2026-119977. The CVE record describes it as arising from predictable, web-accessible staging paths used during full-package core upgrades. That makes it possible for unauthenticated attackers, meaning people with no login, to run code on the server during the upgrade window.
In everyday terms: when WordPress upgrades itself it unpacks the new files in a temporary working area. This bug is about that working area being guessable and reachable from the internet while the upgrade is in progress. Its weakness class is a race condition, an attacker acting in the gap between two steps. The CVE record rates it CVSS 8.1, High.
Two things worth keeping straight:
- It is a WordPress core issue. Plugins and themes are not the cause, so a clean plugin list does not make you safe.
- The announcement does not give exploit detail, and neither do we. CISA's entry also gives none, and does not say how the exploitation was observed. Its entry lists known ransomware use as Unknown.
Who is affected
Potentially every WordPress site. The CVE record lists affected versions from 4.7 through 7.1.3, across all branches in between, up to and including the last release of each branch before this update. WordPress's announcement says the fixes were backported to all branches eligible to receive security fixes (currently through 4.7), and adds a caveat worth reading: only the most recent version of WordPress is actively supported. Older branches are patched as a courtesy, and the backports will ship as they become ready.
The versions to be on
The announcement does not list backport numbers, but the CVE record does the next best thing: it names the last affected release on every branch. The first release above that line is the fixed one, and it matches what WordPress's own update service was offering on 13 November 2026:
| Branch | Last affected | Fixed in |
|---|---|---|
| 7.1 | 7.1.3 | 7.1.4 |
| 7.0 | 7.0.7 | 7.0.8 |
| 6.9 | 6.9.10 | 6.9.11 |
| 6.8 | 6.8.11 | 6.8.12 |
| 6.7 | 6.7.10 | 6.7.11 |
WordPress's documentation pages for 7.0.8 and 6.9.11 both date their release to 28 October 2026 and call them security releases. The CVE record covers every branch back to 4.7 the same way. Ask your developer or host to confirm the exact number on your site, and if it is on an old branch, treat a move to current WordPress as a project, not an afterthought: older branches are patched as a courtesy, and the next fix may not reach them.
How to check your version
- Dashboard. Log in to
/wp-admin. WordPress's documentation says a statement at the bottom of the At a Glance widget tells you what WordPress version you're running. - Command line. If you or your developer have shell access,
wp core versionprints it (WP-CLI). - Dashboard, Updates. The same screen offers the update, covered below.
If you have no admin login at all, that is a finding in itself. Whoever built or hosts the site can read the version in seconds.
Auto-updates or manual?
WordPress's announcement says: if you have sites that support automatic background updates, the update process will begin automatically. Its developer documentation adds that automatic updates are enabled on most sites, with minor releases on by default, and that disabling them is strongly discouraged.
That does not mean every site updated. Hosts and agencies often switch updates off, pin versions, or stage them on a copy first. Your site can also be running a branch that has not yet received its backport. Do not assume. Check the number.
To update by hand, WordPress's instructions are to open the Dashboard, click Updates, then Update Now. Before you do, take a backup and confirm it restores. WordPress's own documentation calls verifying the backup essential. On a store or a site with custom code, have your developer run it on a staging copy first.
What to check after updating
CISA's catalog entry marks this vulnerability as requiring forensic triage for US federal agencies, because it has been exploited. That is a government requirement, not guidance for small businesses, but the logic carries over: patching closes the door, it does not tell you whether someone already came in. The following checks are our own good practice, not an official WordPress procedure:
- Administrator accounts. Open Users, filter by Administrator, and look for any you do not recognise.
- Unfamiliar files. Ask your host or developer to list files changed recently in the WordPress root and in
wp-content, especially PHP files in the uploads folder, which should hold media only. - Redirects and spam. Unexpected redirects, new pages, or spam appearing in Google results are signs to act on.
- When your site last upgraded. The flaw sits in the upgrade window, so ask your host when core updates last ran on your site.
If something looks wrong, do not tidy it up quietly. Our guide to what to do in the first 24 hours after a website is hacked covers containing it and keeping evidence.
A message you can send your developer or host
Copy, paste, fill in your domain:
WordPress 7.1.4 (28 October 2026) fixes CVE-2026-119977, which CISA lists as known exploited. Which exact WordPress version is [your domain] running right now? If it is below the fixed release for its branch, on what date will it be updated? Please also confirm whether automatic core updates are enabled, and whether anyone has checked administrator accounts and recently changed files since 28 October.
A competent answer contains a version number and a date. If it contains neither, you have learned who owns your site's security, and the answer is nobody.
The bigger point
This is the second exploited-vulnerability warning for website owners in a fortnight, after php2shell, the PHP flaw that also reached CISA's exploited list. Both are fixed by updates that someone has to own. Our website security guide for UAE businesses covers the wider checklist, and if you are weighing whether a platform that needs this much watching is right for you, read WordPress or a custom website.
If nobody currently owns updates, hosting and monitoring for your WordPress site, our WordPress service includes that ownership. Tell us what you are running and we will tell you where you stand.
Versions, dates and guidance are as published by WordPress.org, CISA and the CVE Program on or before 13 November 2026. Check wordpress.org for later releases.