English
Deutsch
PolskiWordPress 7.1.2: A Critical Security Fix for Page Template Resolution
Contents
WordPress released version 7.1.2 on 22 September 2026 to fix a vulnerability classified as critical. The project recommends immediate updating and also provided fixes for older branches through 4.7. These backports do not mean all historical branches receive active support. [1]
What the advisory establishes
CVE-2026-87902 / GHSA-7hp8-65ch-5whp concerns page-template resolution. Under documented theme and server conditions, an unauthenticated request can cause a readable PHP file outside the theme directories to be included, potentially leading to remote code execution. The affected 7.1 versions are 7.1.0 and 7.1.1; the fix is 7.1.2. [2]
Remote code execution means that an attacker may cause the server to run code. “Conditional” matters: the advisory is not a statement that every installation has already been compromised. Equally, an uneventful homepage visit is no proof that an installation is patched.
A short operational check
The update procedure should start with a recoverable backup of files and database. The official update documentation describes dashboard and manual routes. [3] After installation, recording the actual version and checking representative pages provides clearer evidence than merely noting that automatic updates are enabled.
- Record the installed version for each installation, including staging and less visible sites.
- Apply the relevant official security release and record the outcome.
- Check the homepage, an ordinary page, a post, login and an important form.
- Review update failures separately instead of assuming every installation completed successfully.
What a checksum check can and cannot show
Where WP-CLI is available, the following read-only commands report the version and compare core files against published checksums. --include-root also warns about unexpected items in the root directory. [4]
wp core version
wp core verify-checksums --include-rootA checksum result is evidence about the files covered by that check. It is not a full investigation of plugins, themes, database content, accounts or earlier activity. Unexpected files need assessment rather than automatic deletion.
Editorial status: 27 September 2026. This report covers the release and its documented scope. It does not claim exploitation on a particular website or certify the security of an installation.
Questions and answers
Is it enough that automatic background updates are enabled?
As an expectation, yes; as evidence, no. Since version 3.7, WordPress installs security releases within a branch, such as 7.1.2, on its own by default. Whether that actually happened on a given installation depends on conditions that are not visible from the outside:
- The constants
AUTOMATIC_UPDATER_DISABLEDorWP_AUTO_UPDATE_COREinwp-config.php, or theauto_update_corefilter in a plugin, can switch the update off or restrict it. - If a version control directory such as
.gitor.svnsits in the installation directory or above it, WordPress skips the automatic update. - The updater needs write access to the files without asking for FTP credentials; without it, the update does not take place.
- The update is triggered by WP-Cron. If
DISABLE_WP_CRONis set and no system service callswp-cron.phpregularly, it does not run at all.
WordPress reports the outcome by email to the administration address. If that address leads to a mailbox nobody reads, a failure goes unnoticed as well. The installed version, recorded for each installation, is therefore the more reliable evidence.
What does the backport to branches as old as 4.7 mean for an installation on an older branch?
It receives a security release within its own branch and can be protected against this one vulnerability without the jump to 7.1. Nothing more: other fixes and compatibility work are not necessarily carried back, and officially only the current version is maintained. The backport buys time for the actual upgrade; it does not replace it.
Is there a comparable checksum check for plugins?
Yes, wp plugin verify-checksums --all. It compares the files of installed plugins with the checksums WordPress.org publishes for the respective version.
Its limit is the same source: plugins that do not come from the WordPress.org directory, such as purchased or custom-built ones, have no checksums there, and WP-CLI skips them with a warning. The command does not cover themes. A clean result therefore applies only to the plugins that were checked; for the rest, the remaining option is a comparison with a known clean copy.
Related articles
