WordPress 7.1.4 and checking security updates

What the October 28 release fixes

You receive an automatic update notification for a business website. The homepage works, but the hosting panel still shows 7.1.3. Before restarting anything, identify the site concerned and when each screen recorded its version. An email may refer to a staging copy. The panel may also show an inventory collected before the operation. Reading the version on the active installation tells you whether action is needed.

WordPress released security version 7.1.4 on October 28, 2026 and called for a prompt update. Its advisory describes, among other things, a flaw during upgrades, several stored script injection possibilities and access control issues involving certain editor data. The advisory describes flaws fixed in core. It cannot, by itself, determine whether a particular site was exploited. A suspicious access alert needs its own investigation, even after the patch is installed.

When checked on November 10, 2026, the official archive placed 7.1.4 among the latest stable releases. The 7.0 branch also listed 7.0.8, dated the same day as 7.1.4. The package's presence in the archive offers no guarantee of future maintenance for that branch. WordPress 7.2 appeared among the prereleases. Check the stable release section when you carry out the work and follow the security release appropriate to your installation and its maintenance policy. If a newer stable release is already installed, keep it.

Identify the installation you need to check

Start with the public domain and its corresponding administration path. In the hosting panel, find the connection between that domain and its directory or environment. Record the displayed name, the version observed and the time. An agency may have three almost identical entries for the main site, the staging clone and the old migration installation. The correct identifier is the one that links the public address to the environment handling its requests.

If you use the dashboard, open the administration area for the intended domain directly and check the address after logging in. Record the installed version under Dashboard → Updates. On a multisite network, also check the Network Admin dashboard. Subsites sharing the same core do not each require a separate copy of its files. They may nevertheless have different uses, such as a store on one subsite and forms on another. Include both in functional checks.

A maintenance service notification may use its own naming convention. If you do not know which site it refers to, match its installation identifier to the one in the panel. For a WordPress site hosted and maintained by a third party, ask for the production core version and deployment time for the exact domain. A general status such as “maintenance completed” does not always specify which version was installed. On a service that manages core for you, use this route instead of trying to replace its files through another interface.

Prepare a backup you can actually restore

The security advisory calls for prompt action. Take the time needed to obtain a usable rollback point, then proceed with the update. Identify the file backup and database backup, when they were taken and who can restore them. A database-only copy will not restore core files. A file archive will not recover an order, note or change stored in the database. The configuration file contains sensitive information. Keep your copies outside public directories and restrict access to the team responsible for rollback.

For a store, record the last known order and when the work begins. This helps prevent the loss of recent writes if restoration becomes necessary. If the site receives many changes, coordinate the maintenance window with the person managing orders or content. Decide who monitors the site and who can involve the host. The work record must state where the rollback point is located, what it contains and when it was taken.

If a staging copy is already available, use it to test the most important functions, such as a form, an interactive block or the login page. Disable real sending and processing in this copy according to your host's procedure. Use a test payment if the workflow requires one. Keep the expected results from before the update. If the copy already shows a problem, record it so it is not later attributed to the patch. On a small site, a few targeted checks and an accessible rollback point are often more useful than a long generic list.

Check or install from the dashboard

If the dashboard already shows the expected stable security release, move on to functional checks. Your host or WordPress may have performed the operation in the background. If the version is older and you manage core directly, open Dashboard → Updates and read the update offered. Compare the version number and release type against the stable channel. Check compatibility notes for your essential components, especially when upgrading from an older branch, which changes more than a point patch.

A site may display a maintenance screen during the update. Observing an error during this window is not enough to declare failure. Keep the operation's output and check its status before submitting a second request. If the interface says another update is in progress, check the background job or ask the deployment owner whether it is still active. This avoids two concurrent operations on the same files.

If buttons are missing, first identify who owns the delivery mechanism. A site whose core is supplied by a package, container image or deployment recipe may prohibit changes from the dashboard. In that case, the correct action is to update the reference artifact and deploy it through the usual mechanism. Changing a single folder on the server could produce the correct version for a few hours, until the old package is redeployed.

1. Check that the administration area matches the domain and environment you just recorded.
2. Confirm the rollback point. If the panel manages core updates, follow that panel's procedure.
3. Start the appropriate stable update through the designated interface and wait for the result.
4. Return to the updates screen and record the version actually installed.
5. Open a public page and check the main workflow selected before the work began.

Read the version and verify files with WP-CLI

With terminal access, obtain the core path from the panel or deployment documentation. Replace the example path with the confirmed path. Run wp core version first. The response concerns the files at that location. If you see an unexpected number, check that the command reads the same directory used by the public site. A newer clone in a neighboring folder can return a plausible result without telling you anything about production.

When the intended folder does correspond to the 7.1.4 package in French for France, the second example asks WP-CLI to compare core files against the checksums for that version and variant. Adjust both options to the installed package. A site whose administration area is displayed in French may use files from a package in another language. Check the variant actually deployed with your host or in your build procedure. On an installation using a newer stable release, use its version number. Do not use this example to reinstall 7.1.4.

The verification command reads the files and retrieves checksums from WordPress.org. It does not trigger an update. A match attests only to the files the command compared in that directory. It does not check the database, plugins, accounts or the server that actually responded to the browser. A mismatch calls for a careful review of the reported path. A different package variant, an incomplete deployment or a local modification can cause mismatches. If the checksums cannot be reached, record the check as incomplete and verify server connectivity without disabling TLS validation.

wp --path=/chemin/vers/wordpress core version
wp --path=/chemin/vers/wordpress core verify-checksums --version=7.1.4 --locale=fr_FR

Check multiple servers or multiple sites

For a site spread across several servers, use the deployment as the unit of verification. An SSH connection may take you to just one node. Ask the person responsible to record the version or artifact identifier on every group serving requests. Include automatically added instances and those returning to service after maintenance. An old deployment image can bring an outdated node back online even when existing instances are current. In a phased deployment, also check that replacement of the old instances has finished.

For a portfolio of sites, one tracking row per installation is enough. Record the domain, environment, versions before and after, observation time, deployment mechanism and name of the person responsible for checking. Add a result for the public page and the main function. For sites sharing one core, group the version at core level, then separately record the functions checked on the subsites. This distinction avoids clicking the same update several times while overlooking a critical network use case.

Investigate inconsistencies before clearing caches. If the panel still shows the old version while production uses a verified package, find the date of the panel's last inventory. If a node still serves an old package, have its deployment corrected. Purging the page cache can refresh the HTML served, but it does not replace PHP files. On a managed site, pass the observed times, versions and environments to the person who can connect the browser to the infrastructure. Avoid relying on a number retrieved from HTML as the sole proof of an update.

Check that visitors can still take action

First open a public page in a private window. Check the title, relevant images and navigation. Then perform the action that makes the site useful. For a service website, send a controlled test submission and confirm receipt. For a store, complete a staging order in the designated environment. For a magazine, open a draft preview and check a block used in published articles. A homepage served from cache may work while the administration area or a form fails.

If your site relies on an interactive block, reproduce an identifiable action before and after the work. For example, check moving to the next page of comments with the same article and browser. If teams use notes on content, test a dummy note with the designated accounts and check that each person sees only what their role permits. These tests concern expected functionality. They do not attempt to reproduce the vulnerabilities described in the advisory.

If a check fails, record the address, time and exact action. Check whether the problem occurs with one account, one component or several pages. Compare the site's logs with the time of the change. A form may fail in staging because outgoing email is deliberately disabled there. In that case, the test must check the expected behavior in that environment, such as a message captured by the staging system. Do not enable production transport to make the test artificially pass.

Handle a mismatch and prepare rollback

If files differ even though the version number has changed, keep the mismatch list and check the package variant. Then compare the result with your deployment procedure. A modification to core files may disappear during an update. Identify why it exists before overwriting it. If core is delivered through a reproducible artifact, redeploy from the reference source corrected by your maintainer. If unknown files or suspicious activity appear, preserve useful evidence and have the security owner examine the site. Simply reinstalling core does not address changes affecting the database or plugins.

If a business function fails after the patch, first determine whether a specific component is responsible and whether a compatible version allows you to keep the patched core. Repeat the test on a copy, changing one thing at a time. If returning to a previous state becomes necessary, have the operations owner approve that choice. A full database restore can delete orders and publications received since the backup. Record those writes and choose what to recover before any global restoration. Rolling back to a vulnerable core must remain a temporary measure, with the update resumed as soon as possible.

You can close the work when the expected stable version matches the installation responding to the public and the selected functions have been checked. Record what was observed, who performed the checks and which discrepancies remain open. For a managed site, link the result to the maintainer's report. If you can verify only some instances or subsites, identify them. This record lets you resume verification precisely after the next deployment.

Keep the historical example without freezing future updates

Documentation check dated November 13, 2026: the official archive consulted presents WordPress 7.1.4, released on October 28, as the latest stable version. This is a dated observation; it is not an instruction to remain on that number after a new release. The guide keeps 7.1.4 as an identifiable security patch example.

For a site administered with WP-CLI, first confirm the stable version offered and the team's deployment mechanism. After a backup and validation on the copy, wp --path=/chemin/vers/wordpress core update targets the latest available version by default. Do not run this command on core managed through an image or package: update that artifact. If a database migration is requested, run wp core update-db on the verified target; on multisite, the operation must be planned for the network.

Then record the version actually installed and repeat file and functional checks. A “Success” update output does not attest to form delivery or the availability of every node.