Critical PHP vulnerabilities make hosting a business decision

WordPress security advice usually points to the dashboard.

The latest critical PHP release is a reminder that the dashboard is only one layer of a live website.

On October 21, 2026, the PHP project announced two critical vulnerabilities that can allow unauthenticated remote code execution. The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The PHP security team says the issues affect PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.

This is not a WordPress core vulnerability. The WordPress announcement says no WordPress update is required or planned. It is a runtime security issue that can affect any server hosting a PHP application.

That distinction matters commercially. A business can have a fully patched WordPress dashboard while the server underneath it is still running an exposed PHP build.

What changed

The PHP project describes two critical issues, both rated CVSS v4.0 9.2 in its advance notice.

The first, CVE-2026-109618, involves out of memory handling. The second, CVE-2026-109619, involves stale global state across requests. The published advisory says both can lead to unauthenticated remote code execution.

The PHP team also reports a demonstrated exploit for one path before application code runs, with the highest risk considered to be on Apache deployments using mod_php. That does not mean every WordPress site is equally exposed, or that every affected site has been compromised. It does mean the security boundary is below WordPress and cannot be assessed by looking only at plugins, themes and core updates.

The fixed versions are:

• PHP 8.2.35
• PHP 8.3.36
• PHP 8.4.27
• PHP 8.5.12

The PHP project says PHP 8.1 and older no longer receive updates from the project. Some operating system distributions and long term support vendors may provide backported fixes, but that needs to be confirmed with the vendor rather than assumed.

PHP 8.2 is also due to reach end of life on December 31, 2026. Updating an older server to PHP 8.2.35 may address the immediate vulnerability, but it should not be mistaken for a durable platform decision.

Why this matters to small businesses

For a small business, the PHP version can feel like somebody else's infrastructure detail. It is often controlled by a hosting provider, agency or developer. The commercial responsibility still lands with the business when the website handles enquiries, customer accounts, payments, bookings, files or internal administration.

Remote code execution is serious because it can let an attacker run code on the server without first signing in to WordPress. The practical consequences depend on the server configuration, application permissions, isolation between sites and the data reachable from that environment. They can include loss of website integrity, exposure of application data, changes to outgoing communications or disruption to business workflows.

Those are possible consequences, not evidence that every site will experience them. The useful response is proportionate urgency: establish the actual runtime, patch it through the right owner and verify the business functions that depend on it.

This is also why the issue should not be reduced to a WordPress update checklist. WordPress can report one PHP version in Site Health while a hosting environment has several pools, containers or application paths. A managed host may have already applied the vendor patch. A self managed server may still be waiting for an operating system package, a control panel update or a restart of every PHP worker.

For WooCommerce stores, the risk sits beside an existing compatibility decision. WooCommerce recommends and is fully compatible with PHP 8.3 or newer, and WooCommerce 11.6 is planned to require PHP 8.1 or newer. The WooCommerce advisory for the PHP security release also says that stores hosted on WordPress.com, WordPress VIP, Pressable and WP Cloud were already protected against the disclosed issues. That is useful evidence for those platforms, but store owners should still confirm their actual environment and understand who owns future remediation.

Who needs to act

The first group is any business running PHP 8.2 through 8.5 on an internet facing web server that has not received the October 21 security fixes.

The second group is businesses running older PHP versions. Older versions may not have a current upstream fix, so the decision may involve a supported distribution, a hosting migration or a controlled PHP upgrade rather than a normal version update.

The third group is businesses that do not know who is responsible. If the website is managed by an agency, the hosting provider controls the server, and a separate supplier maintains an integration, the urgent question is not only, "Has somebody patched it?" It is, "Which PHP runtime serves the live site, who can change it, and what evidence will confirm the change?"

Businesses using a hosting platform that has published a clear protection statement should keep that statement with their operational records. It is not a reason to ignore the issue. It is a reason to document the platform boundary and the remaining checks owned by the business or its suppliers.

What businesses should do now

1. Find the effective PHP version

In WordPress, start with Tools, Site Health, Info, Server. Check the hosting control panel as well. Record the PHP version, server type if available, hosting provider and the person responsible for the environment.

Treat that as an inventory step, not complete proof. A site can be served through more than one process, and a control panel can show a preferred version while a live pool has not yet restarted. Ask the host or infrastructure owner which fixed package is serving public requests and when the workers were restarted.

2. Confirm who owns the patch

If the site is on managed hosting, ask the provider whether the fixed PHP package has been applied to the live environment, whether all relevant PHP workers have restarted and whether any WAF rule is only a temporary mitigation.

If the business or its developer manages the server, follow the PHP or operating system vendor's update path. Do not install a random PHP binary into production because the version number looks right. Package source, extensions, process configuration and restart behaviour all matter.

The WordPress guidance says a WAF may help mitigate the vulnerabilities, but site owners should still check with their host and update PHP when necessary. A WAF is not a replacement for the fixed runtime.

3. Move to a supported target

Apply the fixed release for the current supported branch as soon as the owner can do so safely. If the server is on PHP 8.2, treat PHP 8.3 or newer as the strategic target because PHP 8.2 reaches end of life at the end of December.

Do not bundle an urgent PHP security update with an unrelated redesign, plugin replacement or large configuration clean-up unless the existing environment makes a smaller safe change impossible. The smaller the immediate change, the easier it is to verify and recover.

4. Test the business paths

After the update and worker restart, test the paths that matter to the business:

• contact and enquiry forms;
• customer login and password reset;
• checkout, payment and order confirmation;
• booking, membership or application flows;
• transactional email and webhooks;
• scheduled jobs, imports and exports;
• administrator publishing and media uploads;
• key landing pages and search paths.

The checklist should match the site. A brochure website does not need a full commerce test suite, while a WooCommerce store should not be signed off after somebody checks the homepage.

5. Record the result

Keep the old version, fixed version, update time, responsible person, environment and test result in the same place as other website operations records. Record any failed test and the decision taken.

That evidence is valuable when a supplier says an update was applied, when a checkout issue appears later or when the business needs to decide whether the site should receive deeper investigation.

6. Escalate when the runtime cannot be secured

If a self managed system cannot be updated promptly, the UK National Cyber Security Centre guidance linked by WordPress says organisations should consider taking the system offline until it can be fully mitigated when immediate remediation is not feasible.

That is not a casual recommendation for every small website. It is a reminder that an exposed runtime is an infrastructure risk, not a minor plugin issue. If the site cannot be patched, isolate it, preserve relevant logs and get a qualified technical decision about the next step. Do not rely on an untested configuration tweak as proof of safety.

Where technical judgement is required

The first judgement is whether the platform has actually been patched. A host email, a green dashboard notice or a WAF rule may each be useful evidence, but none answers every question. The effective PHP version, worker restart and application path need to be understood together.

The second judgement is choosing between an emergency fix and a platform move. PHP 8.2.35 may be the fastest responsible way to close the immediate issue for a compatible site. PHP 8.3 or newer may be the better destination when the business is already operating on an old host or preparing for WooCommerce 11.6. The right sequence depends on compatibility, ownership, backups and the time the business can tolerate for testing.

The third judgement is deciding how much investigation the exposure period warrants. A site that was patched promptly and shows no warning signs may need documented verification. A site that stayed exposed, handles sensitive information or shows unusual files, accounts, traffic or outgoing messages may need a focused security review before normal operations continue.

The fourth judgement is deciding what not to change. Emergency work creates pressure to update everything at once. That can make a failure harder to diagnose and can hide whether the original issue was resolved. Apply the security change, test the business paths and create a separate plan for broader maintenance debt.

This is the kind of work that belongs in Website Growth & Care. The value is not only keeping a version number current. It is keeping the live website supportable, observable and able to recover when the layer underneath the CMS changes.

A focused Website Audit can establish the actual runtime, hosting responsibility, update path and evidence gap when nobody has a reliable answer. If the site is already constrained by old hosting, fragile extensions or an unclear deployment process, Website Development may be part of the longer term platform decision rather than an emergency reaction.

When the hosting provider, agency, developer and business owner each own part of the system, a Fractional Technical Partner can help turn those boundaries into one decision record: what is exposed, what must happen now, who owns it and what should be improved after the immediate risk is closed.

The practical standard

The critical PHP release is not a reason to panic, and it is not a reason to wait for the next WordPress dashboard update.

It is a reason to verify the runtime that serves the live site.

A practical response has six parts:

1. Identify the PHP version and execution environment.
2. Confirm who owns the patch and whether all workers are covered.
3. Update to a fixed supported release.
4. Test the business workflows that matter.
5. Record the version, timing, owner and result.
6. Escalate or isolate the system if it cannot be secured promptly.

WordPress is still the application businesses see and manage. PHP is part of the system that keeps it running. When a critical vulnerability reaches that layer, hosting ownership becomes a business decision.