WordPress 7.1.4 fixes an upgrade-window flaw: confirm the patch reached every site

WordPress released version 7.1.4 on October 28, 2026, with security fixes that include a weakness capable of allowing remote code execution during the upgrade window. The release announcement recommends updating immediately. For owners of multiple sites, the first task is to establish which installations have actually received the fix.

Sites supporting automatic background updates begin the process automatically, WordPress says. That describes how an update starts, not confirmation that it finished on every server. An enabled setting, an old maintenance checklist or a host's general update policy is not a substitute for checking the installed version.

The upgrade process is part of the security fix

The announcement credits Umut Bayram with reporting the upgrade-process weakness. It also lists stored cross-site scripting issues affecting areas including the Interactivity API, Customizer selective refresh and Privacy Data Removal Requests, plus a stored denial-of-service issue. The bundled root certificates are updated because of the eMudhra revocation.

Other fixes address unauthenticated discovery of unpublished Customizer changesets and access to post notes by privileged users who cannot edit the attached post. These are different permission and exposure problems. The announcement does not establish that a particular site has been attacked, or that every issue has identical exploitation conditions.

The version documentation adds detail on affected components and permissions. It is useful for the administrator assessing a specific installation. For the owner deciding whether to act, the release's immediate-update recommendation is already clear; the upgrade-window issue is not a reason to postpone the repair.

Verify completion, then check the site works

Open each site's Dashboard, choose Updates and inspect the current version. For the current stable branch, the target in this release is 7.1.4. Where the update remains available, use Update Now or arrange the update with the person responsible for hosting. Reopen the screen after completion and record the resulting version.

WordPress's update instructions recommend backing up first and explain that one-click failures may involve filesystem permissions. A useful maintenance record should therefore include the site, installed version, backup location, result and any unresolved error. A failed update belongs on an active work list, not in a completed column.

After the update, check a public article, administrator access and an essential publishing action. These checks establish whether the site remains usable; they do not constitute a security audit. Use a prepared staging and rollback plan, and make sure the backup and restore checks cover a recovery you can actually perform.

Older branches need an exact version, not reassurance

The announcement says security backports extend through branch 4.7 and were still being shipped. The version documentation now lists patched older releases, including 4.7.39, while stating that 4.6 and earlier no longer receive security updates. Only the latest WordPress version is actively supported. Check the listed patch for the branch actually installed; the existence of backports does not make every old installation safe.

If a site cannot be updated today, contact its host or maintainer with the version and blocking error, assign a responsible person and set a concrete recovery or upgrade time. Ask for a site-specific containment assessment while the repair is arranged. Do not treat a backup, a firewall or a promise to update later as proof that these vulnerabilities are fixed.

The same announcement says 7.2 Beta 3 contains applicable fixes and gives December 8 as the planned 7.2 release date. The release archive distinguishes beta testing from production releases. A future major version is not a reason to leave a current security update pending.