Update, 7 October 2026: WordPress 7.1.3 supersedes 7.1.2 as the latest mainline security and maintenance release. This article preserves the September 22 fix and its verification guidance; do not treat 7.1.2 as today’s update target. See our WordPress 7.1.3 owner update guide and the official October release announcement. The official release archive separately lists the 7.0.7 older-branch package.
WordPress 7.1.2 was released on September 22, 2026. WordPress calls it a security release and recommends updating immediately. If you run a business website, first find out which WordPress version is actually installed. Then plan a controlled update and check the paths customers and staff use. A working homepage alone cannot confirm either protection or a successful deployment.
The official WordPress announcement describes one critical-severity fix in page-template resolution. It says an unauthenticated attacker could, under certain server and theme conditions, cause WordPress to include a readable PHP file outside the active theme; additional conditions could lead to remote code execution. That is a reason to patch promptly. It is not proof that a particular site was attacked. This guide stays with owner actions and does not reproduce attack steps.
Which update does your site need?
Go to Dashboard > Updates and record the installed WordPress version before clicking anything. Check the official release archive independently if your host manages updates or your dashboard shows an unexpected target. WordPress 7.1.2 was the mainline patch when this article was published. As of 7 October 2026, WordPress 7.1.3 is the latest mainline release; follow the current official update target rather than stopping at 7.1.2. The version documentation lists 7.0.6 as the fix for the affected 7.0 branch. An earlier security patch, including 7.1.1 or 7.0.5, does not by itself include the September 22 fix.
| What you find | Next safe action | What still needs proof |
|---|---|---|
| WordPress 7.1.2 is installed. | Record that the September fix is installed, then plan the current 7.1.3 security and maintenance update and verify business workflows. | Version alone does not show when the patch arrived or whether earlier suspicious activity occurred. |
| WordPress 7.1.1 or earlier in the 7.1 series. | Take a current recovery point and apply the latest supported update through the normal update path. As of 7 October, the mainline target is 7.1.3. | Test forms, checkout, login, uploads and editing after deployment. |
| WordPress 7.0.4 or 7.0.5. | Arrange a supported update. The September version documentation lists 7.0.6 as that affected-branch fix. Check the current branch release separately; 7.0.7 is the newer October security package. | Confirm that your host’s update target contains the fix; do not assume an older patch is enough. |
| The host reports an automatic update, but the dashboard still shows an older version. | Ask the host which installation and environment it updated. Record the dashboard result and time. | An email or a cached page is not proof that production WordPress was patched. |
Other older branches have their own backport versions in the official documentation. Check the branch-specific package rather than inferring the version number from another branch. Older backports are a courtesy; WordPress reminds owners that only its latest version is actively supported.
How to update without losing today’s orders or leads
The security fix is urgent, but a rushed database restore could destroy fresh transactions. Before changing files, record the current version, a complete backup timestamp, the person who can restore it and any orders or enquiries received since that backup. Confirm there is enough disk space and a known route into hosting if wp-admin becomes unavailable. A verified files-and-database recovery point matters more than a reassuring backup plugin badge.
Use the normal WordPress Dashboard update or your established managed-host update process, following WordPress’s updating instructions. Do not install a release candidate or an unsolicited package link on production. If the update stalls, preserve the exact error and seek the cause before repeatedly clicking Update Now.
For a WooCommerce store, coordinate a brief test window with the person responsible for orders. Use gateway sandbox or an approved controlled test, not a live payment that nobody has authorized. On sites where an automatic update already ran, start with the installed-version check and the verification plan below.
Prove the site works after the patch
Record the installed version after the update. Then check one meaningful example of each workflow your site depends on. Use a fresh private browser session as well as the signed-in admin view so a cache or an authenticated preview does not hide a broken public path. This is a recommended acceptance plan, not a claim that Webless has tested your installation.
| Path | Evidence to record | Stop condition |
|---|---|---|
| Public pages and mobile navigation | Representative pages load cleanly, menus work and the latest content appears without an error. | Blank page, redirect loop, missing page or unexpected content. |
| Staff login, editor and media | Expected roles can sign in, edit a safe draft and upload a permitted test image. | New permission errors, failed saves or missing image processing. |
| Enquiry or booking path | Open the form or booking flow; arrange an approved test and confirm delivery at the destination. | A form only looks submitted, or an appointment is offered without the intended capacity rule. |
| WooCommerce cart and checkout | Check cart persistence, shipping and payment visibility; reconcile an authorized sandbox order end to end. | A real payment succeeds without a matching order, or a live customer is asked to retry blindly. |
| Background work and logs | Review new PHP errors, scheduled jobs and relevant security alerts after the update time. | Repeated fatal errors, unexplained files or new administrator access. |
Do not clear every cache or disable every plugin as a first diagnostic step. Capture the failing URL, time, role and error; then change one thing at a time with a rollback plan. Our checkout testing checklist covers the full transaction path, and our restore test guide helps establish whether a backup can actually be used.
When is this an incident rather than an update task?
A vulnerable version is a patch priority. It does not prove compromise. Conversely, installing the fix cannot erase changes an attacker might have made before the update. Escalate to an investigation when you find an unfamiliar administrator, unexplained file or page changes, spam or redirect behaviour, or security logs that identify suspicious activity. Preserve timestamps, the affected paths and a recovery copy before making broad changes. Keep credentials and customer data out of ordinary contact messages.
If the only problem is update compatibility, a maintainer can compare the exact error with plugin and theme versions and repair the broken path. If there is evidence of unauthorized change, Webless’s hacked WordPress site recovery route is a more appropriate starting point. The two jobs have different evidence and scope; neither should be sold to someone solely because they received a release notice.
For ongoing work, WordPress maintenance provides an owner for updates, backups and post-update checks. Keep a short dated record of the version before and after, the backup used, the tests completed and unresolved issues. That record is much more useful than “updated” in a chat message.