WordPress shipped 7.1.4 on 28 October 2026, a security release covering what the project counts as 22 vulnerabilities across 17 advisories. Most need an account on the site first. One does not, and it is the reason to patch this week rather than next.

What happened

The serious one is a weakness in the core upgrade process that can lead to remote code execution during the update window. When WordPress installs or updates anything, it unpacks the package into wp-content/upgrade/, a directory the web server serves like any other. Before 7.1.4 the extraction folder took its name from the package, so for anything uploaded through the admin the path was fully predictable, and the cleanup routine deleted the index.php that stops the folder being listed.

For the few seconds an update runs, a complete WordPress installation, including its installer script, sits at a guessable and browsable URL. An attacker who reaches it in that window can run the installer against a database they control inside someone else's document root. Version 7.1.4 appends sixteen random characters to the folder name and stops deleting index.php.

Patchstack, which analysed the release, scores the attack complexity as high and does not call it practical to exploit, because the attacker has to hit a seconds-long window that only opens during an update. It still requires no account and no user interaction, and the window returns on every update, including unattended ones.

The rest of the release is XSS and access-control work. Seven advisories trace back to the Interactivity API: KSES allows any data-* attribute, and every Interactivity directive is a data-* attribute, so a Contributor could store directives that the browser runtime acted on when a visitor loaded the page. A separate issue let unauthenticated visitors discover unpublished Customizer changesets, and another allowed Notes to be read and deleted by a role holding comment-moderation rights without edit access to the post.

Who is affected

Every WordPress site not yet on 7.1.4 or a same-day backport, and especially sites that hand out lower-privileged accounts.

• Sites on 7.1.x below 7.1.4, and on 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, 6.5.14, 6.4.14 or 4.7.39 depending on your branch
• Sites on 4.6 or older, which received no backport at all and are now permanently exposed
• Any site where the hosting stack serves wp-content/upgrade/ to the web, which is what turns the race condition into a practical problem
• Any site with Contributor, Author or Editor accounts held by freelancers, agencies or marketing staff

What to do now

Update core to 7.1.4 or your branch's backport, then block web access to wp-content/upgrade/ at the server so the RCE window cannot be reached even during the next update.

• Run the update from Dashboard, then Updates, or let background updates apply it, and confirm the version afterwards rather than assuming.
• Add a web server rule denying wp-content/upgrade/ and confirm the directory is not listable. Between updates it should hold nothing but an index.php.
• Do not rely on a WordPress security plugin to block this path. The extracted copy loads WordPress from its own files and the site's firewall never runs for that request.
• Audit who holds Contributor and above. All but two of these issues start with an account at that level.
• Plan an upgrade path for anything still on 4.6 or older, because the backport line has ended for those installs.

What this means for South African businesses

Most South African SMEs do not run one WordPress site, they run a marketing site plus two or three older sites nobody remembers, and those older sites are where Contributor accounts get handed out to whoever built them. The XSS issues in this release need exactly that: a low-privileged account, and an admin who later opens the affected post or Customizer screen.

My judgement is that the upgrade-window RCE will not be mass-exploited, because the timing is awkward, but the stored XSS chain will be, because it needs nothing more than a forgotten contributor login on an unmaintained site. Treat 4.6-era installs as compromised-by-default and get them rebuilt rather than patched.

Source: Patchstack analysis of the WordPress 7.1.4 security release, and the official WordPress 7.1.4 announcement.

Also on the blog

• Synology DSM CVE-2024-10441: Ransomware Encrypts Unpatched NAS Boxes (CVSS 9.8)

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.