Critical PHP Update: What WordPress Owners Must Do

If your business runs WordPress, ask your hosting provider to verify its PHP security update today. On 21 October 2026, the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, known as PHP2Shell. Updating WordPress or its plugins alone does not replace the PHP software running on your server.

The immediate task is to establish whether your website is running a fixed PHP build. The PHP security advisory calls for immediate updates. WordPress’s own security notice confirms that this is a PHP issue and that no WordPress update is required or planned for these flaws. You do not need to wait for your site to break, display a warning or show signs of a breach.

Security information checked on 22 October 2026. The steps below are a practical response guide, not a diagnosis of your particular website.

What is the PHP vulnerability affecting WordPress?

PHP is the server-side software that executes WordPress code. These flaws are in that underlying runtime, rather than a particular WordPress plugin or theme.

Both PHP advisories carry a Critical severity rating: 9.2 out of 10 under the Common Vulnerability Scoring System (CVSS v4.0). They concern different memory-handling failures:

• CVE-2026-109618 involves unsafe request cleanup after an out-of-memory condition.
• CVE-2026-109619 involves a worker retaining references to memory from an earlier request after that memory has been freed.

Successful exploitation can allow an attacker to execute code without logging in. The score describes severity, not a 92% probability that your site will be hacked. Exploitability depends on the build, configuration and reachable behaviour. The demonstrated out-of-memory attack against Apache mod_php can run before WordPress starts, which is why an application-level security plugin cannot replace the runtime patch.

The PHP warning also covers installations using PHP-FPM, CGI, FrankenPHP and LiteSpeed. Do not assume a different hosting handler removes the need to check. Ask the provider to assess the configuration actually serving your domain.

Which PHP versions contain the fixes?

The following are the first fixed upstream releases for the four maintained branches. Use the relevant patched release, or a later supported update that includes these fixes. The Canadian Centre for Cyber Security alert lists the same thresholds.

Important: distribution packages can use different numbers. Hosting providers may install a vendor-backported fix while retaining an older-looking PHP base version. For example, Ubuntu’s USN-8948-1 security notice lists php8.3-fpm 8.3.6-0ubuntu0.24.04.13 as corrected for Ubuntu 24.04 LTS. The full package revision matters.

Therefore, neither “we use PHP 8.3” nor “the number looks lower than 8.3.36” settles the question. Request the installed package revision and the vendor notice covering both CVEs.

PHP 8.1 and earlier are outside regular upstream support. Some vendors provide extended-support fixes, but coverage must be confirmed. Treat emergency patching and migration to a supported branch as separate decisions; do not turn an urgent correction into an untested major-version upgrade.

What is the actual risk to your business?

For a shop, booking site or lead-generation website, the consequences of a successful attack could include interrupted sales, altered pages, exposed information or unauthorised access to resources available to the web-server account. That does not automatically mean full administrator or root access to the server.

There is a reason to act now rather than leave this in next month’s maintenance backlog. In its 21 October report, Cloudflare reported attack traffic targeting customers, including attempts to bypass its protections. Those observations are not a count of successful compromises and do not prove that your website has been breached.

The sensible response is urgent verification followed by a controlled patch. A working homepage, a clean-looking dashboard or a successful malware scan does not establish that the runtime contains these fixes.

How to update PHP safely on a WordPress site

1. Find the person who controls the server runtime

On managed WordPress hosting, start with the host. For a cloud server, container deployment or agency-managed environment, identify the engineer responsible for PHP packages and running processes. The person editing your pages may not control either.

In WordPress, open Tools → Site Health → Info → Server and record the PHP version. WordPress documents this check and the hosting update process. Use its instructions to find the runtime, but assess the result against this specific security advisory, not a general “PHP 8.3 or newer” recommendation.

Ask for the website-serving runtime. A developer’s command-line PHP version can differ from the version handling visitors. Include other domains, staging sites and old deployments that remain publicly accessible.

2. Protect recovery before changing production

Confirm a recoverable backup, who can restore it and which business functions need checking. Preserve relevant logs before routine retention or cleanup removes them. Agree who approves the change and who checks the result.

Keep the change focused. Where a fixed package exists for your current branch, assess that route before combining patching with unrelated plugin replacements or infrastructure changes. Test material compatibility risks without allowing an open-ended review to leave production exposed.

3. Install the fix and replace the running processes

The work is not finished when a package manager reports success. The patched runtime must serve real requests. PHP workers are the server processes handling those requests. Ask the administrator to restart or replace all relevant workers using the host’s supported procedure. Container-based systems need a patched image and deployment, not merely a refreshed tag in a build file.

Wordfence’s PHP vulnerability testing and remediation guidance highlights this distinction between installed software and the active web runtime. These are vendor findings, not tests conducted by Powercode Group.

4. Verify security evidence and business functions

Record the full package or image reference, the notice covering both vulnerabilities, and the restart or deployment time. Confirm that requests now reach the patched runtime across the relevant workers and instances.

Then check the site as a customer and editor: homepage, key landing pages, login, contact-form delivery, uploads and scheduled jobs. For a shop, use the payment provider’s sandbox or an agreed controlled checkout test. Do not create real charges or customer messages accidentally.

“A patch is only complete when the website is running it and the business functions still work. Ask for evidence of both, not just a message saying the update was installed.”

Bohdan Semenov, Head of Delivery at Powercode Group

Send this question to your hosting provider

You do not need to understand PHP internals to request an accountable answer:

Please confirm whether the PHP runtime serving our domain is fixed for CVE-2026-109618 and CVE-2026-109619. Provide the active web PHP version and handler, full vendor package revision or container image reference, and the advisory confirming both fixes. Confirm when all relevant workers or instances were restarted or replaced, which environments were checked, and whether any exposure or follow-up work remains.

Classify the reply into one of three states:

• Unknown: the host has not supplied runtime and patch evidence. Keep the request open and escalate it.
• Affected and unpatched: agree urgent remediation. If the patch cannot proceed, ask a qualified administrator about restricting exposure at the server or edge.
• Patched and loaded: retain the evidence and complete the functional checks. Investigate possible previous compromise separately if there are warning signs.

A WordPress maintenance-mode page may still execute PHP. It is not equivalent to preventing public requests from reaching the vulnerable runtime. Avoid copying emergency memory or server settings from social media; incomplete mitigations can create availability problems of their own.

Questions WordPress owners are asking

Will updating WordPress or installing a security plugin fix PHP2Shell?

No. WordPress core, plugins and themes are separate from server PHP. Keep them maintained, but obtain confirmation that the hosting runtime has received both fixes. A plugin update is not runtime patch evidence.

Does Cloudflare or another firewall mean we can wait?

No. Cloudflare recommends patching even with its protections in place. Firewall coverage depends on the applicable controls and whether traffic can reach an origin through another route. Treat it as an additional defence, not completion of the repair.

Our host says the site is patched, but Site Health shows an older number. Who is right?

A vendor backport may explain it. Ask for the complete package revision and matching security notice, then confirm that this build is running. A base version alone cannot establish the answer in either direction.

Does patching prove nobody accessed the site earlier?

No. Patching closes the corrected vulnerability; it does not establish the site’s previous history. Unexpected files, accounts, processes or connections warrant investigation. Preserve evidence and involve the host or a security specialist rather than deleting suspicious material blindly.

What if the patched version breaks a plugin?

Use the agreed recovery plan and address the incompatibility with the host or developer. Returning an old vulnerable runtime to unrestricted public service is not a safe final state. A temporary isolated service or static alternative may be necessary while a compatible patched route is prepared.

Need help checking or fixing your WordPress PHP runtime?

Powercode Group can help you assess this issue and scope the remediation through our cybersecurity audit and remediation services. If the work needs infrastructure changes or additional engineering capacity, our Cloud and DevOps engineers provide a relevant route.

Contact Powercode Group about your PHP update with your website URL, hosting provider and the answer you have received so far. Do not send passwords through the enquiry form. We can agree the scope, access method and costs before changes begin.

Once the urgent repair is complete, use our guide to choosing full-time or part-time DevOps support to decide who owns future maintenance. A small site does not necessarily need a full-time engineer. It does need a named person responsible for security updates and verification.