WordPress 7.1.2 Security Update: CVE and Safe Checklist

Reviewed 24 October 2026. WordPress 7.1.2 fixed a critical core vulnerability on 22 September, but it is no longer the current release. The official release archive lists 7.1.3, released on 6 October, as the latest stable version at this review. If you are updating now, use the current stable release after compatibility checks; do not stop at 7.1.2.

This guide explains what the September fix covered, which older versions received it, and how to update a working website with a usable recovery plan.

What did WordPress 7.1.2 fix?

WordPress 7.1.2 was a security-only release led by John Blackbourn. It addressed one critical vulnerability, CVE-2026-87902, also tracked as GHSA-7hp8-65ch-5whp. It did not introduce new editing or layout features.

The official WordPress announcement describes an unauthenticated attacker causing page-template resolution to include a readable local PHP file outside the active theme directories. When the necessary theme and server conditions exist, that can result in remote code execution: attacker-controlled actions running on the server.

The version documentation identifies wp-includes/template.php as the revised core file. Updating the active theme alone does not apply that core patch.

Was this vulnerability actively exploited?

Yes. CISA's 25 September alert identifies this CVE as a new Known Exploited Vulnerabilities catalog entry, based on evidence of active exploitation.

That confirms real attacks. It does not establish that every vulnerable site was compromised, or that your own site was attacked on release day. A site's incident history requires its own evidence.

Why do the theme and PHP configuration matter?

The WordPress security advisory gives the exploit prerequisites:

• The active parent or child theme has a top-level directory beginning with page-, such as page-templates.
• A suitable local PHP file exists and is readable by the web-server account.
• A documented route to code execution additionally depends on PHP configuration, including register_argc_argv.

The advisory identifies affected examples involving default cPanel configurations with PHP before 8.5 and the official PHP Docker image. Actual deployment settings still matter.

Ask your host to inspect the PHP configuration serving your domain. Command-line PHP can use different settings from PHP-FPM or another web handler. A firewall rule or configuration mitigation may reduce exposure, but applying the core fix remains necessary. Do not delay patching while trying to prove that your theme makes the site immune.

Which versions were affected, and which received backports?

The advisory includes 7.1.0–7.1.1 and older affected releases on branches down to 4.7. The table shows selected branch ranges and the first September fix, not today's recommended installation targets.

Intermediate branches also received fixes; consult the complete official backport list. WordPress states that 4.6 and earlier no longer receive security updates.

A backport fixes a particular issue; it does not give an old branch the same support as current WordPress. For example, the release archive now lists 7.0.7 and 6.9.10, superseding the September patches shown above. If a legacy site cannot move immediately, confirm its newest available branch patch and arrange a tested migration to current WordPress.

Why updating only to 7.1.2 is no longer enough

WordPress 7.1.3 arrived on 6 October with seven security fixes and four bug fixes. These included issues involving comments, exports and embeds. A site still running 7.1.2 therefore misses later fixes.

Check the stable release offered through Dashboard > Updates against the official release archive. If you discover this article later, repeat that check rather than treating its review-date version as permanently current. A beta or release candidate is a testing build, not the production update target for this checklist.

For the October release details, see our WordPress 7.1.3 update guide.

Safe WordPress security update checklist

Treat these as completion checks. Clicking an update button is one step; confirming the result is another.

1. Identify the installation and its dependencies

Open Dashboard > Updates to check core. Record the active theme, plugins, builder extensions and PHP version. Note whether this is a multisite network, shop, membership site or ordinary content site.

For command-line access, run WP-CLI as the site's operating-system account and specify the correct installation path. Replace the example path:

wp --path=/absolute/path/to/wordpress core version
wp --path=/absolute/path/to/wordpress core check-update

The second command checks the WordPress version API. Its documented options include --force-check to bypass the cached result on supported WP-CLI versions.

In cPanel, match the domain's document root with the installation in your WordPress management tool. A scan can miss an old staging copy, subdomain or installation outside the folders you expected. Include those copies in the inventory.

2. Make the backup recoverable and private

Back up both the database and files, including uploads, themes, plugins, configuration and relevant server rules. A database export by itself is not a complete site backup.

Store a protected copy away from the hosting server and outside every public website directory. SQL exports and migration archives can contain customer information and credentials. Confirm that the backup completed and restore it into an isolated test environment; a download success message does not prove recoverability.

For a busy shop, record when the backup was taken. Orders and registrations created afterwards must be preserved or reconciled before a database rollback. Follow the WordPress backup guidance. Our cPanel migration and backup guide covers related file and database handling.

3. Test on staging without creating customer side effects

Match production's PHP version, extensions, theme, plugins and important cache settings. Restrict access to the clone and prevent indexing. Use payment sandbox credentials, suppress real customer emails and disable outgoing integrations that could create duplicate orders or notifications.

Test the intended update sequence, then repeat it on production. Do not overwrite a live shop's database with the staging database after new orders have arrived.

For an actively exploited issue, keep testing focused on critical workflows. If staging is unavailable, ask your host for a recoverable emergency update plan and temporary containment; an open-ended testing delay leaves the exposure unresolved.

4. Update core, then handle themes and builders deliberately

For most owners, the simplest route is Dashboard > Updates > Update Now. Confirm the success result and installed version. Your hosting panel may also offer WordPress management; available tools depend on your plan.

With WP-CLI, after backup and compatibility checks:

wp --path=/absolute/path/to/wordpress core update
wp --path=/absolute/path/to/wordpress core update-db
wp --path=/absolute/path/to/wordpress core version

Core update normally selects the latest version. Its --minor option stays within the existing branch; it does not move an obsolete installation to the current branch. For a deliberate major-version move, test compatibility first.

Database update runs the core database upgrade procedure when needed. On a confirmed multisite network, its --network option handles all sites' core database updates. Plugin-specific migrations may require separate attention.

Apply compatible theme and plugin updates in the sequence you tested. Back up custom theme changes before updating; modifications made directly to a parent theme may be overwritten.

For Elementor: check the free plugin, Pro and third-party add-ons together. Elementor's update troubleshooting guidance specifies the free plugin first, then Pro; if core is outdated, update WordPress first. Follow the vendor's current requirements and test the editor, saved layouts and frontend. Updating two packages in the same session does not by itself prove compatibility.

Remove unused plugins and themes deliberately. Preserve any required parent theme and a suitable maintained fallback theme.

5. Verify the live website

Purge the site's relevant page, object and CDN caches after a successful update. Then test both logged-out and authenticated views.

A checkout page loading does not prove a payment completes. Use sandbox testing where supported and coordinate any production transaction test to avoid unintended charges or messages.

Keep the backup and change record until you have checked the site's next important scheduled tasks.

Do automatic updates guarantee the patch installed?

No. Automatic updates can succeed without intervention, but you still need to check the installed version.

WordPress's automatic update documentation explains that configuration constants and filters can change the behavior. Relevant settings include:

• WP_AUTO_UPDATE_CORE: 'minor' enables minor core updates; true enables all core update types; false disables them.
• AUTOMATIC_UPDATER_DISABLED set to true: disables automatic updating.

A host may manage deployment separately. Review the existing policy before editing configuration, and use one authoritative update process. File ownership, disk capacity or outbound connectivity can also prevent an attempted update from finishing.

For each site, record the installed version after the change rather than relying only on an update email.

What if the update fails or the site breaks?

Preserve the error message and time before changing anything else.

• Another update is in progress: establish whether a real job is running. Only after confirming the lock is stale should an administrator remove core_updater.lock, as described in the WP-CLI core update documentation.
• Stuck in maintenance mode: confirm the update has stopped and inspect the installation. WP-CLI provides maintenance-mode status and deactivation commands; clearing maintenance mode alone does not repair a partial update.
• Download or filesystem errors: check disk quota, ownership, permissions and outbound HTTPS. Fix the cause rather than making the entire website world-writable.
• Fatal error or broken builder: use the error log to identify the failing component, then repair or restore the compatible set tested on staging.

If rollback is necessary, preserve new orders and other changes before restoring the database. Keep a site reverted to vulnerable code contained while a patched, working deployment is prepared.

Does a successful update prove the site was never hacked?

No. Patching closes the documented entry point; it does not remove an attacker's existing files or accounts.

An additional core integrity check is:

wp --path=/absolute/path/to/wordpress core verify-checksums

This WP-CLI command compares core files with official checksums. Investigate mismatches, allowing for the installed version and locale. A passing result is limited to the files checked: it is not a malware clearance for plugins, themes, uploads, the database or the hosting account.

If you find unfamiliar administrators, unauthorized changes or suspicious redirects, involve your host or incident responder. Preserve logs and a protected evidence copy, contain the affected account, restore or rebuild from clean sources, close the entry point and rotate exposed credentials. Use the official hacked-site recovery guidance to organize the response.

Separate October 2026 check: PHP also needs patching

On 21 October, WordPress published a critical PHP security notice. It concerns separate PHP runtime vulnerabilities affecting PHP applications, not just WordPress. The notice says no WordPress update is required or planned for those PHP issues.

Ask your host to confirm the patched PHP package serving each domain, including any vendor backport. Tools > Site Health > Info > Server shows the website's reported PHP version, but package-level patch confirmation may require your provider. A patched WordPress core does not establish that the underlying PHP runtime is patched.

Managing several client sites

Use a per-site record with the domain, owner, before-and-after versions, backup location, completion time and test results. Separate sites that updated successfully from those that failed or were temporarily contained.

Start with internet-accessible installations still on affected versions, prioritizing high-impact shops and membership sites. Include staging and forgotten subdomains. For shared hosting fleets, assess the account and server boundaries if compromise is suspected.

Hostlelo customers can request an update review through their normal support channel. Include the domain, core/PHP versions, active theme or builder, and the exact error if an update failed. Send credentials only through an approved secure method.