The WordPress Vulnerability Your Static Website Doesn't Have

WordPress released version 7.1.2 on 22 September 2026 to fix a critical vulnerability in its own page-template handling. Two days later, New Zealand's National Cyber Security Centre issued an alert about CVE-2026-87902, urging affected organisations to patch and investigate possible compromise.

If you run WordPress, checking that update has been applied is the immediate job. A conversation about rebuilding the website should not delay it.

The part that interests me beyond the patch is where the flaw sits. This is WordPress Core code involved in choosing a template for a page. A site can carry that code because it runs an elaborate publishing operation, or because somebody chose WordPress ten years ago to display six service pages and a phone number.

Those are rather different requirements. They can still leave someone with the same urgent update to organise.

What this vulnerability actually allows

CVE-2026-87902 affects page-template resolution through get_page_template(). Under particular conditions, an unauthenticated request can cause WordPress to include a readable local PHP file outside the intended theme directories. Depending on the file and server configuration, that can lead to remote code execution: attacker-controlled code running on the server.

The WordPress security advisory specifies prerequisites involving both the active theme and the server. These include a suitable top-level theme directory beginning with page-, and an existing local PHP file the web-server account can read. The documented route to code execution depends on additional PHP environment conditions.

This is a serious Core vulnerability, but it does not mean every WordPress installation can immediately be taken over. Robert Ressl's original research is explicit about the conditions used in his laboratory tests. A demonstrated exploit in a prepared environment does not establish that every default installation has the same exposure.

WordPress has backported the fix to older branches, reaching back to 4.7. Check the advisory's patched version for the branch you actually run. A version number below 7.1.2 does not, by itself, prove that the security fix is missing. Nor should a courtesy backport be treated as a long-term maintenance plan for an ageing installation.

The attempts have already moved beyond probing

As of 25 September 2026, this is more than a theoretical concern. Patchstack's updated firewall-telemetry report describes probing on 22 September, followed by attempts to write PHP files and deliver code-execution payloads in its 23 September update.

Observed attack requests do not establish that every targeted site was compromised. They do establish a reason to act promptly and examine the available evidence. Ask whoever maintains the site to apply the appropriate fix, check the installed version and review relevant request logs and unexpected file changes. The NCSC alert also calls for investigation of possible unauthorised access.

This is the distinction I covered in the Mathspace article about patching and incident response. Updating the software addresses the weakness. It does not tell you whether somebody used it beforehand.

What is running when somebody opens your website?

A traditional WordPress installation brings together PHP, WordPress Core, themes, plugins and a database. It usually also has an administrator login, scheduled background jobs and connections to other services. An uncached page request can execute server-side application code to assemble the response.

Caching can reduce how often that happens. It does not automatically remove the application or make every dynamic route inaccessible.

Each component has a maintenance job attached to it. Someone needs to follow advisories, apply updates, check compatibility and investigate failures. A plugin that has not been touched for years can still be part of the public application.

A static generator such as Eleventy does the page-building work before publication. The public site can then serve HTML, CSS, JavaScript, images and other assets without running WordPress or querying its database to assemble pages for visitors. A blog does not inherently require a public database; its articles can be built into HTML too.

Code that is not running on the public server cannot be exploited through a runtime vulnerability that depends on that code existing there.

That is the relevant difference in this incident. A static site with no publicly reachable WordPress/PHP runtime does not expose the affected WordPress template-resolution path. It has removed the component this particular attack needs.

Static delivery still needs looking after

I would be wary of anyone describing a static website as impossible to hack.

Its hosting account, domain registrar, DNS and TLS configuration still matter. Deployment credentials, Git repositories and automated build pipelines can provide a route to changing what visitors receive. Build dependencies need maintenance. Third-party JavaScript can run in visitors' browsers, and a contact form still sends information to a service somewhere.

An administrator account with poor protection can undermine a very simple website. So can a forgotten WordPress installation left online beside the new one.

The security benefit depends on what has actually been removed and how the remaining services are managed. Exporting static pages while leaving the old CMS publicly accessible does not retire its vulnerabilities. If WordPress remains as a private publishing backend, it still needs patching and access controls appropriate to that role.

This is the same practical question raised by old servers and technical debt: which services still need to exist, and who is responsible for them?

Some websites earn their complexity

A shop handling live orders has a reason to run application software. So does a membership service, a client portal or a publishing team relying on several editors and established approval workflows. WordPress can be a sensible fit for user accounts, e-commerce, dynamic publishing and integrations that genuinely depend on its plugin ecosystem.

For those businesses, I would concentrate on maintaining it properly. Patch promptly, remove unused plugins and themes, protect administrator access with MFA, monitor logs and keep recoverable backups. Give someone clear responsibility for the work, including what happens when an update breaks something.

Migration is not automatically the better answer. Rebuilding useful WordPress functionality across half a dozen external services can create another collection of dependencies to manage.

A Sydney consultant's website containing services, an about page, locations, testimonials, a blog and an enquiry form deserves a different assessment. It may have no customer accounts, memberships, complex shop or dashboard. If most of its plugins exist to keep the underlying platform working, I would ask what benefit the business receives from keeping that platform public.

Does the website still need the runtime complexity it currently carries?

For suitable sites, static delivery can reduce the patching burden, plugin dependency, hosting complexity and page-generation overhead. The content-editing arrangement needs to suit the people using it. My earlier article on when a WordPress brochure site should become static covers that decision without assuming every business should make the same move.

Start with the maintenance arrangement

Before discussing a rebuild, I would ask a small-business owner a few fairly ordinary questions:

• Who monitors WordPress advisories, and how quickly do they apply critical updates?
• How many plugins are installed, and which are still needed?
• Who has administrator access, including former staff and suppliers?
• Who checks logs and tests that backups can be restored?
• Which business functions actually require the current CMS?

“It's included in the hosting” needs a little more detail. Hosting the files, patching WordPress Core, maintaining paid plugins and investigating a possible compromise may be different responsibilities. The agreement should make that clear before an urgent advisory arrives.

Apply the current security fix first. Then use the answers to decide whether the longer-term job is better maintenance, different hosting or a simpler architecture.

Solway Web Consulting offers a WordPress migration service for businesses whose sites no longer need a full CMS, alongside WordPress reviews and hosting migrations where keeping it is appropriate. If your site still runs WordPress mainly because that was the platform chosen years ago, a review can establish whether it is still doing useful work for you.