WordPress released 7.1.2 on 22 September 2026 to address a security vulnerability. The official announcement says it fixes a critical-severity vulnerability and recommends updating sites immediately. For a small business, the sensible response is a controlled update with a short verification checklist, with a named person responsible for completing the checks.
What the release fixes
The issue affects page template resolution. Under specific server and theme conditions, an unauthenticated attacker could make WordPress include a chosen readable local PHP file outside the active theme directories. The WordPress team says that combination could lead to remote code execution. That’s a serious outcome, but the published description matters: the preconditions still need to be present on the individual site.
WordPress also says the fix has been backported to supported security branches through version 4.7. For sites that can move forward, target the current release: the project actively supports only the latest version.
Read the official WordPress 7.1.2 release notice for the advisory details and CVE/GHSA reference.
Check these four things before updating
1. Confirm the current version.
Record the version shown in Dashboard > Updates, or check it through your hosting control panel. This gives you a clean before-and-after record and prevents a team member from assuming that somebody else has already applied the fix.
2. Take a usable backup.
Keep both the database and the files, and make sure the backup is stored somewhere separate from the live hosting account. Test the backup restore before relying on it. For a business-critical site, record the restore time and who can perform it.
3. Check the change surface.
List the active theme, child theme and plugins. Review any custom code that changes template loading or routing, including changes your team made outside the normal update process. Don’t delete or disable code simply because its name looks unfamiliar; identify its owner first.
4. Choose a quiet maintenance window.
Publish a temporary maintenance message if the update is likely to interrupt the site. Tell whoever manages forms, bookings or online sales when testing will start and finish. A small amount of coordination is easier than discovering a broken enquiry form from a customer.
How to test after the update
Apply the release to a staging copy first when one is available. Test the home page, one standard content page, the main navigation, search, forms and any logged-in workflow. Check the browser console for new errors and clear caches where the update requires it. If the site uses a page builder, open a representative page in the editor and confirm that its layout and reusable components still load.
Then repeat the essential checks on production. Confirm the version number, load key pages in a private browser window, submit a test form if the process allows it, and check the site from a mobile viewport. Keep a short record of the completion time, the backup used and the tests completed.
The recent WordPress 7.0.1 maintenance-release checklist covers the same update discipline from a site-owner perspective. The current release has a different security issue, so use the present advisory as the source of truth.
Give each check an owner
For a form, agree where the test message should arrive and ask the recipient to confirm receipt. Seeing a success message in the browser checks only one part of the journey. Record delivery to the expected inbox and confirm that all submitted details arrived. Use harmless test details and remove them afterwards if the form creates a stored record.
For an online shop, choose a test method supported by the payment provider and the site’s configuration. Confirm the order reaches the expected status and notification recipients. Avoid placing an unintended charge on a customer account. If a booking or membership process matters to the business, give it the same treatment: identify the expected result before testing and compare the recorded outcome with that result.
If the update exposes a problem
Don’t keep retrying a failing installation on the live site. Capture the error, note the last successful change and restore the site only if the failure affects visitors or data. On staging, disable plugins one at a time to identify conflicts, then test the suspected plugin against its latest compatible version. If the problem involves custom theme code or template resolution, involve the developer who owns that code before changing it.
Remove temporary maintenance messaging after testing and keep the backup reference, update time and results in the site’s change log.
Author
