WordPress 7.1.4 is a security release announced October 28, 2026. The WordPress team recommends updating immediately. Use the official updater or your host's managed deployment, then verify the code actually serving visitors. A dashboard success message on one installation is not proof that every copy behind your domain has been updated.
What this release changes
The official announcement describes fixes involving the upgrade process, stored cross-site scripting, Interactivity API denial of service, access to unpublished Customizer changesets and notes, and bundled root certificates. Those are reasons to patch, not evidence that your particular site has been attacked. Do not test exploit payloads on a live business site.
Backports to eligible older branches were still shipping when announced. Check the actual package offered for that branch. The announcement also says the applicable fixes are in WordPress 7.2 Beta 3; beta software is not the production replacement for the stable security release.
Start with the installation that serves the domain
Write down the production hostname, filesystem path, deployment method and responsible operator. Include a public staging copy, a forgotten migration domain and any second serving node. A terminal opened in yesterday's release directory can report a perfectly patched version while the web server still points at yesterday's code.
Confirm a usable backup and the host's recovery procedure. Keep this preparation short and focused on the security update. Do not combine the patch with a theme redesign, database cleanup or unrelated plugin replacement, because those changes make a new failure harder to isolate.
For an authorized operator, these are read-only checks from the correct application directory:
wp core version
wp core verify-checksums
The WP-CLI checksum documentation explains package and locale options. Compare against the intended release and locale. A mismatch requires investigation; it is not a reason to disable TLS verification or quietly exclude unexpected files.
Patch once through the deployment owner
Use Dashboard > Updates, the managed-host update control, or the site's established release pipeline. When the host owns immutable releases, do not patch an individual running container and assume the next deployment will retain it. Ask for the release identifier and evidence covering every serving instance.
If WordPress reports another update in progress, first establish whether an update worker is still running. The update-lock diagnostic explains that separate failure. Deleting a lock while an active process is writing files can turn a delay into an incomplete installation.
Deployment checklist: verify the installed release, core files, customer journey and any separate incident evidence. Synthetic explanatory visual.
Verify normal work without trying to exploit the site
Use an ordinary test draft to check editor loading, saving and preview. Open a representative page containing interactive blocks. Confirm a permitted user can still perform the expected editorial action, then check a lower-privilege account cannot view a private test item it should not access.
Run the site's main customer journey with controlled data: a contact form, a booking inquiry or a sandbox checkout. Confirm both the on-screen completion and the expected back-office record. If the update succeeded but a form notification is missing, preserve that narrower symptom instead of reverting all security fixes immediately.
Record the exact time, release version, node or release ID, checksum outcome and workflow results. Retain the first relevant error rather than an entire log containing private content. The previous 7.1.3 verification guide remains historical context, not today's target version.
Know when patching is not enough
Unknown administrators, unexplained files or suspicious redirects require an incident investigation alongside patching. Core checksum success does not inspect every plugin, uploaded file, database row or active session. Preserve evidence and involve the hosting security team before destructive cleanup.
For an update that cannot complete or a live copy that remains inconsistent, request focused WordPress repair. Supply the installation inventory and redacted failure details, not credentials or customer exports. Close the work only when the intended package is installed and the affected business workflow is verified.
Reference and review date
Primary technical reference. Sources checked October 29, 2026. The proposed procedures and original diagrams are explanatory test aids, not claims of customer testing or measured improvements.