Get concise advice on choosing the right CMS, understanding migration costs, and avoiding expensive implementation mistakes before they become roadmap problems.
On September 22, 2026, WordPress released version 7.1.2 to patch a critical vulnerability in WordPress Core itself.
The vulnerability, tracked as CVE-2026-87902, allows an unauthenticated attacker to manipulate how WordPress resolves page templates. Under the right conditions, this can make WordPress load a PHP file from outside the active theme directory.
That can potentially lead to remote code execution and complete compromise of the website.
No WordPress account is required.
No administrator needs to click anything.
There are important conditions that must be present for successful exploitation, so this does not mean every WordPress website is immediately exploitable.
But WordPress itself classifies the vulnerability as critical and recommends updating sites immediately.
What is CVE-2026-87902?
The vulnerability exists in WordPress's page-template resolution process.
WordPress uses templates to determine how different types of pages should be rendered. The vulnerability makes it possible for an attacker to manipulate this process so WordPress includes a readable local PHP file located outside the directories of the active theme.
This is known as a path traversal and local file inclusion vulnerability.
On its own, loading another local file does not necessarily mean an attacker can execute arbitrary code.
The dangerous part comes when a suitable PHP file exists elsewhere on the server.
Under certain server configurations, an attacker could use that file to move from local file inclusion to remote code execution.
At that point, the impact can become much more serious.
An attacker who achieves remote code execution may be able to execute commands on the server, modify the website, access data or establish persistent access.
That is why the issue has received a critical severity rating.
Is every WordPress website vulnerable?
No.
This distinction matters.
The vulnerable behaviour exists in WordPress Core, but successful exploitation depends on additional conditions being present.
The active parent or child theme needs to contain a top-level directory beginning with page-, such as:
page-templates
The server must also contain a readable PHP file that can be usefully exploited when WordPress includes it.
The official security advisory identifies Twenty Twelve and Twenty Fourteen as examples of WordPress themes with the relevant directory structure.
It also names popular third-party themes including Neve, Hestia and Sydney.
That does not mean every website using one of these themes can automatically be compromised.
The server configuration and available PHP files matter too.
The important distinction is between being affected by the vulnerable WordPress code and having an environment in which that vulnerability can successfully be turned into remote code execution.
Unless you know your theme and server configuration well enough to establish that your site cannot meet those conditions, updating WordPress is the sensible response.
Which WordPress versions are affected?
The vulnerability reaches much further back than the latest release.
WordPress 7.1.0 and 7.1.1 are affected, but WordPress has also released security fixes for older branches all the way back to WordPress 4.7.
For example:
WordPress 7.1 was patched in 7.1.2
WordPress 7.0 was patched in 7.0.6
WordPress 6.9 was patched in 6.9.9
WordPress 6.8 was patched in 6.8.10
WordPress 6.7 was patched in 6.7.9
WordPress 6.6 was patched in 6.6.9
WordPress 6.5 was patched in 6.5.12
WordPress 6.4 was patched in 6.4.12
Security releases were also made available for older branches down to WordPress 4.7.37.
This is particularly relevant for company websites.
A business may have had its WordPress site built five or ten years ago and still be running an older branch.
The website can appear perfectly functional from the outside while the software underneath it continues to age.
What should you do?
If your company website runs on WordPress, the immediate action is straightforward:
Update WordPress to the patched version for your branch and verify that the update completed successfully.
If somebody else manages your website, send them the CVE number and ask them to confirm that the site has been patched.
You can ask:
Is our website affected by CVE-2026-87902, and can you confirm that WordPress has been updated to the patched release for our branch?
You should also check whether automatic WordPress security updates are enabled.
Automatic updates can significantly reduce the window between a security release becoming available and the fix reaching your website.
But "automatic updates are enabled" should not become the end of the conversation.
Someone still needs to know whether updates completed successfully and whether the website continues to work afterwards.
Updating software is only half the job
The response to a security vulnerability is often presented as:
"Just update WordPress."
Technically, that is the immediate fix.
Operationally, there is more to it.
A business website might contain:
WordPress Core
a custom or third-party theme
form plugins
SEO plugins
analytics integrations
caching plugins
e-commerce functionality
custom PHP
JavaScript dependencies
external APIs
hosting infrastructure
An update to one component can affect another.
That means a good maintenance process needs to do more than install updates.
It should also verify that critical parts of the website still work.
Can customers submit the contact form?
Can people complete a purchase?
Are marketing integrations still receiving leads?
Are redirects working?
Are important pages rendering correctly?
Can administrators still manage the content they need?
The more important the website is to the business, the less acceptable it becomes to rely on someone occasionally logging into WordPress and clicking "Update."
Who actually owns your company website?
That is the more interesting question behind vulnerabilities like this.
A lot of companies have a website.
Far fewer have clearly defined ownership of the software running that website.
Perhaps an agency built it three years ago.
Perhaps an internal marketing team edits the content.
Perhaps a freelancer occasionally makes changes.
Perhaps the hosting company performs automatic backups.
Each party is involved with the website, but that does not necessarily mean anyone is actively responsible for monitoring its software dependencies and security advisories. (This ownership vacuum is often the hidden operational cost of running WordPress sites, where routine patching turns into an uncoordinated scramble across disconnected teams.)
Then a critical vulnerability appears.
Who sees it?
Who determines whether the site is affected?
Who installs the update?
Who checks whether the update succeeded?
Who verifies that the website still works?
Who investigates if the vulnerable version had been publicly exposed?
If the answer to those questions is unclear, that is a larger problem than any individual CVE.
A website is a software system
We still often talk about websites as if they were finished marketing assets.
You redesign the website.
You launch it.
The project is complete.
From a technical perspective, that is not really what happens.
The website might look almost identical for five years while almost everything underneath it requires ongoing maintenance.
CVE-2026-87902 is a particularly useful example because the vulnerability is not buried inside an obscure third-party WordPress plugin.
It is in WordPress Core itself.
The correct conclusion is not that WordPress is uniquely insecure.
All actively developed software can contain vulnerabilities.
The important question is whether your architecture and maintenance process allow you to respond when those vulnerabilities are discovered.
This is also an architecture decision
The technology used to build a website determines part of its long-term operational model.
WordPress makes it exceptionally easy to add functionality through plugins.
That can be a major advantage.
It also means that many WordPress installations accumulate a substantial collection of independently maintained components over time.
Each one becomes another dependency that needs to be understood, monitored and updated.
Other architectures move that responsibility elsewhere.
For example, as I discuss in my comparison of Payload CMS vs WordPress mental models, moving from a plugin-and-theme hierarchy to an application-first stack allows more functionality to live directly within the application codebase rather than being assembled from third-party plugins.
That does not remove the security responsibility.
Payload, Next.js, Node.js, libraries and infrastructure all have vulnerabilities and security updates of their own.
What changes is how those dependencies are managed.
They become part of a development workflow where dependency versions can be tracked in code, changes can be reviewed, automated tests can run before deployment, and application behaviour can be verified as part of the release process.
Neither approach eliminates maintenance.
The question is whether the maintenance model fits the organisation operating the website. For teams that decide a plugin-heavy setup no longer matches their operational capacity, my WordPress to Payload migration guide outlines how to transition content models and media into an owned code architecture without risking SEO.
The takeaway
If your company runs WordPress, update your site.
WordPress 7.1.2 fixes CVE-2026-87902 for the current branch, and patched releases have been made available for supported older branches going back to WordPress 4.7.
But after the update is complete, ask a second question:
Who in our organisation actually owns the ongoing maintenance and security of this website?
A website does not stop being software when the design is finished.
Launching it is the beginning of its operational life, not the end.
