WordPress 7.1.2: What to Check After CVE-2026-87902

A WordPress administrator receives a critical security notice, installs the update and sees version 7.1.2 in the dashboard. That is an important job completed. It is also natural to feel that the security issue is resolved.

But the version number answers only part of the question. What happened between the time the site could have been exposed and the moment the patch was installed?

A successful update changes the code that caused the vulnerability. It cannot, by itself, tell you whether someone probed your site, attempted exploitation, changed a file or left anything behind. That distinction matters for CVE-2026-87902, because attack activity was reported soon after the September 22 release. The right response is to patch promptly and check the website's integrity. WordPress release · Government exploitation alert

WordPress released 7.1.2 on September 22, 2026, to address a critical vulnerability in its page-template selection logic. The flaw could allow an unauthenticated request to make WordPress include a readable local PHP file outside the expected active-theme directories. Under the conditions described in the official advisory, this can lead to remote code execution. WordPress release

The conditions matter. The active parent or child theme must have a particular top-level directory layout, and a suitable PHP file must exist on the server and be readable by the web-server account. The path from file inclusion to code execution depends on additional server configuration. An affected WordPress version does not mean every installation was equally exploitable, and exposure does not mean compromise. The official advisory lists the affected and patched releases in each branch. WordPress backported the fix through the 4.7 branch, while emphasizing that only its most recent version is actively supported. Prefer the current WordPress release. If you can't move to the current branch immediately, install the exact patched release for your branch listed in the official advisory. Advisory · Release

WordPress published the security release on September 22. Attack activity was observed within hours of the security release. Initial requests tested whether the vulnerable behavior was present. By September 23, BleepingComputer reported that the observed activity had progressed from reconnaissance to attempts to write PHP files. The Cyber Security Agency of Singapore warned on September 24 that exploitation was being reported.

Those observations show how quickly public information can be used against internet-facing sites. They do not establish whether a particular site was reached, whether a request succeeded, whether a persistent backdoor was installed, or how many sites were compromised. A blocked request in one provider's telemetry shows attacker behavior, not proof of compromise on every WordPress installation.

That is why your own timestamps matter: when was the relevant patch installed on each website, and what evidence exists for the period before and after it?

Patching asks: Is the known vulnerable code still present?
Verification asks: What happened while it was present, and what is the site's state now?

The sequence is vulnerable → exposed → probed or attacked → patched → verified.

A site may never have been exposed under the necessary conditions. An exposed site may have received no relevant traffic. A probe may have failed. A file write or code execution is a different and more serious finding; persistence and confirmed compromise require further evidence. Treat each state separately.

1. Install the appropriate fixed WordPress release. Prefer the current release. If you cannot immediately move to the current branch, install the exact patched release for your branch listed in the WordPress advisory. Also update themes and plugins as part of normal security maintenance.
2. Confirm the update actually completed. Record the installed version and time for each site. Check that scheduled jobs, key pages, login, and checkout still function. An update notification alone is not confirmation.
3. Preserve and review historical evidence. Ask your hosting provider for web-server, WAF, PHP, and security logs covering the period around disclosure and your update. Retain originals before making further changes. Investigate unusual page requests and correlated errors with a qualified administrator; a suspicious request alone does not prove success.
4. Investigate unexpected file changes. Compare files with a known-good backup or baseline, focusing on newly created PHP files, theme and plugin directories, upload locations, and modified configuration. Verify core files against official checksums where applicable. Avoid deleting suspicious artifacts before preserving them if you need to investigate an incident.
5. Review content and database changes. Check for unexpected pages, posts, options, injected markup, altered links, and unauthorized redirects. A site can look normal on the home page while a particular page or visitor path behaves differently.
6. Check what visitors' browsers load. Test representative pages, especially login, product, and checkout flows, from more than one device or session. Review new scripts, iframes, third-party resources, network requests, and redirect destinations. Distinguish an approved marketing or payment integration from an unexplained change.
7. Check reputation and access. Review search/browser warnings and blacklist status. Examine admin accounts, recent sign-ins, and changes to privileged users where logs are available. If evidence suggests compromise, follow an incident process that preserves evidence, removes malicious changes, and resets credentials after the environment is clean. WordPress hacked-site guidance
8. Continue observing the site. Compare later scans, file states, alerts, and visitor behavior against a trusted baseline. The update is a milestone; it is not a substitute for monitoring what the live site does next.

If you manage many WordPress installations, track each site's version, patch time, exposure assessment, investigation result, and verification status separately. An agency-level “all patched” count is useful, but it does not close an unresolved incident on one customer site.

A malware scan is valuable. It can reveal suspicious files, malicious content, redirects, or reputation issues present when and where the scan runs. A free WordPress scan can be a useful starting point for a current-state check.

A clean scan today cannot prove that no attack occurred yesterday. The attacker may have left no lasting artifact, the relevant URL may not have been scanned, or a transient change may have disappeared. Conversely, an unusual file is a finding to investigate, not automatic proof that this CVE was the entry point. Historical logs, trustworthy backups, integrity baselines, and earlier monitoring results answer different parts of the question. If those records were not collected, some historical questions may remain unanswered.

This is also why “verified” should describe the evidence and its limits. For example: “WordPress 7.1.2 installed at 15:00 UTC; available access logs for the prior 48 hours reviewed; no matching suspicious requests found; core files checked; external pages and reputation reviewed; monitoring continues.” That is a useful operational conclusion. It is more precise than declaring that no attack could possibly have happened.

CVE-2026-87902 is one example of a larger problem: a website can change after deployment. Software updates, account activity, plugins, content edits, third-party JavaScript, server configuration, and malicious actions can all alter what visitors and automated systems receive.

The visible page is only one surface. Browser-executed scripts can change a customer journey without obvious defacement. Server-side files can be altered while the home page still looks normal. Redirects and blacklist warnings can affect visitors and reputation. Quttera's broader discussion of website integrity also considers machine-readable content that search engines and other systems interpret. Not every unexpected change is malicious; investigation must establish context.

Continuous Web Integrity is Quttera's way of describing this operating discipline: maintain visibility into the live website, record changes and security signals over time, investigate anomalies, remediate actual threats, and verify the result. A patch is a point-in-time action. Integrity is a state that needs repeated checks and evidence.

ThreatSign Website Security offers ongoing website malware monitoring, reporting, and alerts, with external and server-side monitoring and protection features depending on the plan and access available. Quttera also provides blacklist monitoring. These signals can help an owner notice and investigate changes after a patch and continue watching the website. ThreatSign overview · Plans and monitoring details

ThreatSign is not presented here as a CVE-2026-87902 exploit detector or as proof that an unobserved historical interval was harmless. If you suspect compromise, combine monitoring with available logs, backups, and incident investigation. The goal is a clearer answer to a practical question: is the website clean, trusted, and behaving as expected now, and will you notice if that changes?

Installing the patch was necessary. Finish the job by checking the site and recording what the available evidence can establish. Then keep watching the live website.

Secure My Website