Critical WordPress updates need proof, not assumption

A critical WordPress update is not complete when somebody assumes it happened.

It is complete when the business can confirm the patched version is live and the website still performs the work it exists to do.

On September 22, 2026, WordPress released WordPress 7.1.2 to fix a critical security vulnerability. The official announcement says an unauthenticated attacker can, under certain conditions, cause WordPress page template resolution to include a chosen readable local PHP file outside the active theme directories. If the required theme and server conditions are present, the issue can lead to remote code execution.

The official WordPress security advisory for CVE-2026-87902 assigns the issue a CVSS score of 9.2. It lists affected releases across every eligible WordPress branch from 4.7 through 7.1, and identifies patched releases for each branch.

This is not a reason to claim that every WordPress site was openly exploitable or compromised.

The vulnerability needs specific conditions in both the active theme and the server environment. The original release announcement and advisory did not report active exploitation.

That assessment changed after the release.

On September 24, the Cyber Security Agency of Singapore warned that CVE-2026-87902 was reportedly being actively exploited and that a public proof of concept was available. Patchstack, whose firewall telemetry is cited by the agency, reported attack traffic progressing from reconnaissance to attempts to write attacker controlled PHP files.

The prerequisites still matter. Active exploitation makes verification and proportionate investigation more urgent, but it does not mean every unpatched WordPress site could support the complete attack path.

It is still consequential enough for small and medium businesses to act immediately.

The flaw sits in WordPress core. It requires no authenticated account. The relevant theme condition appears in legacy default themes and several popular third party themes. The relevant server condition can exist in familiar cPanel and container environments.

The update should be urgent. The response should also be precise.

What changed

The vulnerability affects the way WordPress resolves page templates.

Themes can provide different templates for pages. WordPress needs to locate the correct PHP file and include it when rendering a request. The security advisory says an unauthenticated attacker can manipulate that resolution process so WordPress includes a chosen readable local PHP file outside the active theme directories.

Reading or including a local PHP file is not automatically the same as taking over a server.

Remote code execution becomes possible when additional prerequisites are present. The advisory identifies two important groups of conditions.

First, the active parent or child theme must contain a top level directory whose name begins with page-, such as page-templates. The advisory names the legacy Twenty Twelve and Twenty Fourteen themes, along with third party themes including Neve, Hestia and Sydney, as examples where that condition exists.

Second, a suitable local PHP file must exist and be readable by the web server. The advisory explains one known path from that file inclusion to code execution. It says the official PHP image for Docker is affected and that the default cPanel configuration is affected when PHP earlier than 8.5 is in use.

The combination matters.

A site is not confirmed vulnerable to remote code execution merely because it uses one of the named themes. It is not confirmed safe merely because the theme name is absent. The active theme structure, server files, PHP configuration and installed WordPress version need to be considered together.

WordPress 7.1.2 fixes the core issue. The security team also backported the fix to eligible branches through WordPress 4.7. The advisory lists the exact patched release for each branch.

That backporting is helpful for sites that cannot move to the current major release immediately. It should not be confused with a recommendation to remain on an old branch indefinitely. WordPress states that only the most recent version is actively supported.

Why this matters commercially

For a small business, the WordPress version number is rarely the real concern.

The concern is whether the website keeps accepting enquiries, processing orders, supporting bookings, publishing content and maintaining customer trust.

A core vulnerability with a path to remote code execution can put all of those functions at risk. An attacker who can run code with the web server's permissions may be able to alter the site, access information available to that process or interrupt service.

There is also a second risk: a business delays the patch because it is afraid an update will break the website.

That fear is understandable on sites with old themes, custom templates, many plugins or no reliable staging environment. It is not a reason to leave a critical core issue unresolved. It is a reason to have a faster, better controlled update process.

The commercial requirement is continuity.

The business needs enough confidence to apply an urgent patch quickly, verify the result and recover if an incompatibility appears. That is part of Website Growth & Care, not a separate activity reserved for emergencies.

WordPress 7.1.2 also illustrates why automatic updates should be treated as a control, not as proof.

The official release says sites that support automatic background updates will begin the update process automatically. That reduces exposure for many businesses. It does not confirm that every site updated successfully, that a custom deployment included the patch or that checkout, forms and publishing still work afterward.

The business still needs evidence.

Who is affected

Every business running an affected WordPress core release should apply the patched release for its branch or move to the current supported version.

The advisory lists affected releases from WordPress 4.7 through WordPress 7.1.1. That broad range means this is not limited to businesses that installed the latest major release.

The risk deserves particular attention when the site also has one or more of these characteristics:

• an active parent or child theme with a top level directory beginning with page-;
• a legacy Twenty Twelve or Twenty Fourteen theme;
• a theme such as Neve, Hestia or Sydney, which the advisory names as examples;
• cPanel hosting with PHP earlier than 8.5;
• a container deployment based on the official PHP image;
• automatic core updates disabled or tightly controlled;
• a deployment process where WordPress files are replaced only through version control or a container build;
• several client sites maintained by one agency or technical provider.

The theme examples should guide investigation, not create panic.

Switching themes is not the primary fix described by WordPress. Updating WordPress core to a patched release is the direct response. A rushed theme change can introduce visual regressions, broken templates, lost customisation and new downtime without addressing the maintenance problem that allowed the core version to remain exposed.

Agencies should treat this as portfolio work.

Checking one dashboard is not enough when responsibility covers several sites. Each site needs a recorded core version, update result and focused functional check. Sites with custom deployments or unusual update policies should be reviewed first because they are less likely to receive the patch through WordPress's normal background process.

What businesses should do now

First, confirm the live WordPress version.

Do not rely on an update email, a hosting dashboard badge or an assumption that background updates are enabled. Check the version reported by the live site and compare it with the patched versions in the official advisory.

For sites on the current 7.1 branch, the patched release is WordPress 7.1.2. For an older branch, use the advisory's patched version for that branch as the immediate minimum, then plan a move to the current supported release.

Second, create a usable recovery point.

Confirm that a recent backup covers the database and website files, and that somebody knows how to restore it. The existence of a backup job is not the same as a tested recovery path.

Do not let a slow or uncertain backup process become an open ended reason to defer a critical patch. If the site's recovery model is unclear, that is itself an issue to resolve as part of the response.

Third, apply the update through the site's normal deployment path.

For a conventionally managed WordPress site, that may be the dashboard, a host control panel or a management service. For a version controlled or container based site, it may require changing the pinned WordPress release, rebuilding the image and redeploying.

Avoid making unrelated plugin, theme or feature changes in the same emergency release. A smaller change is easier to verify and easier to diagnose if something fails.

Fourth, verify the live result.

Confirm the public site now reports a patched core version. Then test the paths that matter commercially:

• primary contact and enquiry forms;
• checkout, payment and order confirmation;
• booking or membership flows;
• login and password reset;
• content publishing and page editing;
• search, navigation and key landing pages;
• transactional email and important integrations.

The verification should match the website. A brochure site does not need the same checklist as a WooCommerce store, but both need more than a glance at the homepage.

Fifth, record the decision.

Write down the old version, patched version, time of update, person responsible, checks completed and any issues found. Agencies should keep the same record per client site.

That record turns an urgent patch into evidence. It also reveals sites that were missed, blocked or dependent on somebody who is no longer involved.

When more investigation is justified

Applying the patch closes the known core path. It does not answer every question about the period before the update.

The risk is no longer only theoretical. The Cyber Security Agency of Singapore reports active exploitation, and Patchstack says it observed attack traffic on September 22, the day the patch was released. By September 23, Patchstack had seen attempts use pearcmd.php to write attacker controlled PHP files to disk.

Those observations do not prove that every vulnerable site was compromised. Businesses should not announce a breach without evidence, but sites that remained unpatched after public disclosure now have a stronger reason to review the period of exposure.

More investigation is reasonable when the site clearly matched the theme and server prerequisites, remained unpatched after September 22, handles sensitive information or shows unusual behaviour in logs, files, administrator accounts or outgoing traffic.

The scope should be proportionate.

A focused review may check web access logs, recently changed PHP files, unexpected administrator users, scheduled tasks, active plugins and hosting alerts. A higher risk ecommerce, membership or operational site may justify deeper incident support. A simple site that updated promptly and shows no warning signs may need only a documented verification.

A Website Audit can help separate immediate security work from broader maintenance debt. The useful outcome is a clear answer about exposure, update controls and the next responsible action, not a dramatic list of everything that could theoretically go wrong.

Where technical judgement is required

The first judgement is choosing the update path.

The security team provided patched releases for older branches, which gives businesses an immediate option when a major version upgrade cannot be tested safely on the same day. The long term destination should still be a current supported release. The right sequence may be patch first, then modernise in a controlled follow up.

The second judgement is interpreting the prerequisites.

The named themes are examples of the required directory pattern, not a complete list of affected themes. The server examples are important, but they do not mean every cPanel or Docker site can be exploited. A useful assessment checks the actual theme structure and server configuration rather than relying on labels.

The third judgement is deciding how much testing is enough.

Urgency does not remove the need to verify business functions. It changes the order. Apply the focused security patch, test the highest value paths first and expand the check according to the site's complexity.

The fourth judgement is ownership.

On many SMB sites, the host manages infrastructure, an agency manages WordPress, a marketing team controls content and a separate supplier owns one important integration. An urgent core release exposes gaps between those responsibilities.

A Fractional Technical Partner can help define who decides, who updates, who verifies and who communicates when a critical issue appears. The value is not adding process for its own sake. It is removing uncertainty while the decision still matters.

The practical standard

WordPress 7.1.2 is a critical update for a vulnerability now being actively exploited. Businesses should install the patched release immediately.

The stronger lesson is about proof.

An automatic update setting is useful, but it is not proof that the live site is patched. A message from a host is useful, but it is not proof that the business critical paths still work. A developer saying, "it should be fine," is not the same as a recorded version and completed check.

A practical response has five parts:

1. Confirm the affected version on the live site.
2. Apply the patched release through the correct deployment path.
3. Verify the patched version is live.
4. Test the website functions the business depends on.
5. Record ownership, timing and results.

That standard is small enough for an SMB to use and strong enough to make the next security release less chaotic.

Critical WordPress updates do not need panic. They need a fast path from official advisory to verified business continuity.