WordPress's Exploited Template Flaw Needs an Actual Version Check

The most expensive word in a security incident can be 'probably.' The site probably updated itself. The host probably handles that. Our theme probably is not affected. WordPress's latest exploited vulnerability is a reason to replace those assumptions with an actual version check and a named person responsible for the result. The fix exists. The remaining question is whether it reached the systems that need it.

On September 25, CISA added CVE-2026-87902 to its Known Exploited Vulnerabilities catalog, citing evidence of active exploitation. That is a meaningful change in how operators should prioritize the issue: it is no longer merely a weakness demonstrated under laboratory conditions. It does not establish how many websites have been compromised, identify every affected deployment or tell an individual owner what happened on their server.

WordPress released version 7.1.2 on September 22 and urged immediate updating. Its release notice says the security fix was also backported to older branches through 4.7. The project calls those backports a courtesy and explicitly says only the most recent WordPress version is actively supported. An emergency fix for an old branch should not be mistaken for an indefinite commitment to maintain that branch. According to the advisory, fixed releases include 7.1.2 and 7.0.6 for their respective branches. On an older installation, match the running branch against the complete table. A rough comparison with a headline version is not enough.

The underlying failure involves how WordPress chooses a page template. The official advisory says an unauthenticated request can cause it to include a readable local PHP file outside the active theme directories. Under the right combination of theme and server conditions, that becomes remote code execution. A WordPress account is not required. This is not a problem that can be dismissed simply because the administrator uses a strong password. The advisory describes prerequisites in the active child or parent theme, a readable PHP target on the server and relevant runtime settings. It identifies a route involving the PEAR software component. This is a serious exposure, but not a finding that every default installation has an identical attack path. Configuration matters without making the update optional.

Researcher Robert Ressl's account explains the boundary failure: request data passes through early processing, later decoding changes its meaning, and the final file lookup does not adequately confine the destination to a trusted theme directory. Normalizing a path and proving that it stays in the intended directory are different operations. Treating the first as the second is the important design error. Ressl tested WordPress 7.0.2 in isolated local laboratories and explicitly supplied a theme-directory condition needed by the demonstration. He did not measure the prevalence of the complete chain across live websites. The demonstrated execution had the permissions of the PHP service account, not operating-system root. Removing a component used by that chain can obstruct the demonstration without fixing the underlying inclusion flaw. His report also cautions that command-line PHP settings do not necessarily describe the runtime serving web requests.

That careful wording is not academic fussiness. An incident team needs to know whether it is looking at an affected software version, a configuration that permits a particular exploit, an incoming probe or evidence of successful execution. Those are different findings. Collapsing them into 'hacked' can produce unnecessary disruption. Collapsing them into 'not our exact setup' can leave an unpatched application exposed.

The distinction also explains why a severity label cannot do the entire prioritization job. FIRST's CVSS guidance says base scores describe a vulnerability's intrinsic severity, not a complete assessment of organizational risk. Threat activity and the actual environment add information that a base score does not contain. Its framework separately recognizes deployment prerequisites and the difficulty of defeating security protections. For this issue, that means two observations belong together: the dangerous outcome has configuration requirements, and CISA has evidence that exploitation is occurring. Neither observation cancels the other. A useful assessment records the installed release, the relevant environment and the available signs of activity. Debating whether a headline sounds sufficiently critical is a poor substitute for establishing those facts.

Patchstack's published observations show why timing matters. Its initial account described requests probing for the file-inclusion behavior. A September 23 update said requests had progressed to attempts to write PHP files. The original reconnaissance-only description remains on the page as historical context, so quoting that older section alone would misrepresent the updated assessment. This is vendor telemetry, not a census of all WordPress installations. Patchstack also reports variation in request methods, encoding and paths. Its defensive lesson is that a rule or log review anchored to one exact string, source address or user agent is too narrow. Operators should use the advisory's behavioral indicators and investigate unexpected files in context. A request in an access log shows activity against the site; evidence that a file was created or executed supports a different and more serious conclusion.

Independent reporting by The Hacker News adds another observer. It cites Previdian's honeypot detections alongside Patchstack's findings and describes the progression from reconnaissance to exploitation attempts. Those observations support urgency, but a honeypot count should not be presented as a victim count. This report does not estimate total successful compromises or claim a particular hosting provider's customers were breached.

The immediate operating task is straightforward, even if the surrounding response is not. WordPress's update documentation recommends a backup before an update and provides both dashboard and manual procedures. It notes that many installations can apply minor and security releases in the background, while filesystem permissions can interfere with one-click updating. Automatic capability is not evidence that an individual installation completed this release.

For a business owner, the useful request to the person managing the site is specific: identify the running branch, confirm the patched version now installed and record when the change completed. Then verify the pages and workflows the business actually uses. These are proposed acceptance checks, not a claim that every update will fail or that installing a security release requires a redesign. Keep the emergency fix small enough to validate promptly.

Core-file integrity can be checked more precisely than by looking at a version label alone. WordPress's WP-CLI documentation describes a checksum verification tool that compares installed core files with checksums supplied by WordPress.org. It performs that comparison without loading WordPress and supports matching a specific release and locale. That gives an administrator a defined comparison against official files rather than an impression that the installation looks normal. The scope of that result matters. A successful core comparison is not a clean bill of health for the database, every plugin, every theme or every credential available to the application. That limitation follows from what the tool checks. An unexpected difference deserves examination; a matching core does not answer every question raised by a period of exposure. Integrity verification and incident investigation complement one another.

WordPress's hardening guidance places responsibility on both the hosting environment and the application owner. A managed service can cover important work without automatically covering every application choice. The guide emphasizes limiting access, containing damage, maintaining backups and keeping software current. In this case, the practical ownership question is who can verify the PHP environment, who maintains the theme and who can inspect server evidence.

Permissions deserve attention because the service account's reach determines the consequences of code running as that account. The hardening guide recommends restricting filesystem write access and keeping plugins updated, with unused plugins removed. Those controls are defense in depth, not a reason to defer the core fix. Changes also need to respect the application's legitimate needs; indiscriminately locking down a production environment can break the service an operator is trying to protect.

If there are signs of compromise, WordPress's recovery guidance starts with documentation: symptoms, times, recent changes and the hosting environment. It recommends coordinating with the host and preserving a snapshot before cleanup. An infected snapshot is evidence, not a clean recovery image. Preserving it can help explain what happened instead of erasing the trail while trying to restore service. The same guidance warns that reinstalling known application files may leave newly added malicious files behind. It also addresses access resets and changing passwords again after the environment is clean. For an exposed business site, a specialist should determine the appropriate investigation and recovery sequence. Installing the fixed release closes the reported defect; it does not establish that earlier unauthorized changes have been removed.

There is a legitimate operational concern on the other side: a hurried change can disrupt a revenue-generating site. That is an argument for a prepared backup, clear ownership and focused validation, not for an indefinite maintenance queue. If the team cannot immediately complete the update, it should work with its host or security provider on temporary containment while finishing remediation. Temporary protection should have an owner and an exit condition.

The closeout should be concrete enough that somebody else can review it: which installations were checked, which fixed releases are running, what exposure evidence was examined and what remains unresolved. That is a better outcome than a reassuring message that everything should be fine. For a company whose public website is part of its business, patching is not background housekeeping. It is an operating responsibility that needs a verifiable finish.

LaunchPad positionAssign ownership for the core update, runtime checks and evidence review. A patched version, an attempted attack and a clean recovery are different findings.