WordPress PHP Update Needed Now for Two Critical Flaws

10/26/2026

A WordPress PHP update is the only safe fix for two critical flaws, and it happens on the server, not in the dashboard.

Quick Read

PHP released fixes on October 21 for CVE-2026-109618 and CVE-2026-109619, each rated 9.2 out of 10 and each allowing unauthenticated remote code execution.
The fix is in PHP, so updating WordPress core, themes or plugins does not close the hole.
The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP says no complete mitigation exists short of updating.
Sites on PHP 8.1 or older are no longer supported upstream and need a move to a supported branch.
Hosts and agencies that manage PHP for clients decide how fast small businesses get protected.

A WordPress PHP update is now the most urgent maintenance job for any business with a website. On October 21, the PHP project released fixes for two critical flaws, tracked as CVE-2026-109618 and CVE-2026-109619. Each is rated 9.2 out of 10, and each lets an attacker run code on a server without logging in. A successful attack can mean stolen customer data, planted malware or a site knocked offline.

The reach is the problem. PHP runs underneath WordPress, Drupal, Joomla and Magento, and a web technology survey puts it at almost 70% of sites whose server-side language is known. The flaws, nicknamed PHP2Shell by some researchers, surfaced ahead of their planned disclosure date. How many installations are vulnerable was unclear when the patches landed.

Disclosure also came with a warning from government security teams. CERT-EU, the European Union’s computer emergency response team, advised organizations to prepare to patch immediately and, where that was not feasible, to consider isolating internet-facing applications from public networks. The UK’s National Cyber Security Centre issued a similar alert. For a business running an online store, that fallback means taking the shop offline, which is a revenue decision most owners would rather not make.

WordPress PHP Update Is a Hosting Task

The fix is in PHP, not in WordPress. Updating WordPress core, themes or plugins does not replace the PHP engine on the server. A WordPress PHP update happens at the hosting level, through a control panel setting or a request to the provider.

The PHP security patch comes as a fixed release for each supported branch: 8.5.12, 8.4.27, 8.3.36 and 8.2.35, according to a host’s advisory published the same day. PHP’s own release notes for 8.4.27 say there are no complete mitigations and that updating is the only safe choice. Workaround tips that circulated on social media before the patch were unconfirmed, so they are not a substitute for the update.

Checking takes a minute. In the WordPress dashboard, open Tools, then Site Health, then the Info tab. The Server section lists the PHP version. Hosting control panels usually list the PHP version too, and many let the owner change it. Some providers do not offer that option, which makes the request to the host the only route. If that number is below the fixed release for its branch, the site is behind.

Sites on PHP 8.1 or older are a separate problem. Qualys threat research head Saeed Abbasi said the upstream project no longer supports those versions, which makes them a priority for upgrade planning. That leaves an upgrade to a supported branch as the route, and it can break older themes and plugins. A backup before the switch and a test on a staging copy where one exists are sensible precautions.

Hosts and Agencies Decide How Fast Sites Get Patched

Businesses with their own IT staff face an inventory problem before a patching problem. One developer urged teams to hunt for forgotten installations, including old Docker images, vendor appliances and neglected WordPress subdomains. A campaign microsite nobody has touched in two years counts.

Businesses that outsource face a speed problem they do not control. A provider that pushes PHP updates centrally can close the gap for every customer at once. A provider that leaves the setting to each customer cannot, and the customers least likely to act are the ones who do not know the setting exists. Agencies that built a site and moved on to the next client carry the same problem. Providers that patch fast and report it clearly gain a concrete selling point. Providers that stay quiet invite customers to ask why.

The attack picture was still forming. At disclosure, active exploitation had not been established, but a proof-of-concept was already circulating on social media. That status should be treated as out of date.

Site Owners Need Written Answers From Their Hosts

Four questions belong in a written message to the host or agency today.

Which PHP version does each site run, including subdomains and staging copies?
When will each move to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or later?
Who tests the theme and plugins on the new version before the switch?
What is the plan for any site stuck on PHP 8.1 or older?

A host that cannot answer the first question by the end of the week has already answered the rest.

A WordPress site on a pre-patch PHP version is running a publicly disclosed critical flaw, and PHP itself says no complete mitigation exists. The upgrade costs a backup, a compatibility test and a host’s attention. Skipping the WordPress PHP update costs customer data, a compromised server or a shop pulled offline.

FAQs

Does a WordPress update fix the PHP flaws?
WordPress core updates do not change the PHP engine on the server. Only a newer PHP release closes these flaws, so the WordPress PHP update has to come from the host or whoever manages the server. Plugin and theme updates leave the PHP version unchanged.

How do I check which PHP version my site runs?
The version appears in the WordPress dashboard under Tools, Site Health, Info, in the Server section. Hosting control panels also list it. Compare the number against the fixed release for its branch.