Critical PHP Security Update: How to Protect Your Website

On 21 October 2026 the PHP project shipped a critical PHP security update. It patches two PHP vulnerabilities that can let an attacker run code on your server without logging in (remote code execution, RCE), and it affects almost every website and web application built in PHP, including WordPress, WooCommerce, Laravel and Drupal. This guide explains what the flaws mean, how to check your PHP version, and how we can patch it for you now.

What matters here

• Two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0.
• No login and no bug in your own code is needed to attack them.
• Fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Updating is the only complete fix.
• PHP 8.1 and older get no official fix. If you run them, plan an upgrade.
• On shared hosting your provider usually applies the update, but you should confirm it has happened.

What the PHP security update fixes

The PHP team describes two flaws in how PHP manages its internal data while it handles a request:

• Out-of-memory corruption (CVE-2026-109618). If PHP runs out of memory part-way through a request, internal data can be left half-initialised. The clean-up that follows may then treat that invalid data as valid.
• Stale state between requests (CVE-2026-109619). Data that belongs to one request can outlive the memory behind it. A later request served by the same worker may use it before it is reset.

Both can lead to remote code execution. The PHP team rates the risk highest for Apache with mod_php, where they have demonstrated an attack that works before your application code even runs. A well-maintained, fully updated WordPress site is therefore not protected if the PHP underneath it is unpatched. The technical detail is in the official PHP security advisory.

Who is affected by the PHP vulnerability?

According to the advisory, every PHP installation that serves web requests is affected: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. That covers practically every way of running a PHP site, including:

• WordPress and WooCommerce sites, whatever plugins they use.
• Applications built on Laravel, Symfony or plain PHP.
• Customer portals, booking systems and internal tools.
• Legacy systems nobody actively maintains any more.

The last group carries the most risk. A system nobody has touched for years often runs PHP 7.4 or 8.0, which receive no official update. The PHP team has published minimal source patches for 7.4, 8.0 and 8.1, but applying them means building PHP yourself, and it does not replace moving to a supported version.

How we can patch PHP for you

If you do not have the time or the people to handle it, we take care of it from start to finish:

• PHP version check. We find out which version your websites and systems actually run, including servers on distribution packages where the number does not tell the whole story.
• PHP update. We update PHP on your server, or work with your hosting provider, and confirm the new version is live.
• Temporary mitigation. If the update has to wait, we apply the recommended measures correctly so they actually take effect.
• Upgrade from PHP 7.4, 8.0 and 8.1. We update plugins, themes and custom code, test on a copy and move you to a supported version.
• Testing after the update. We check forms, logins, payments and the error log so you know the site still works.
• Ongoing maintenance. With our software maintenance service we keep PHP, WordPress and plugins current, so the next security release does not catch you out.

How to check your PHP version

• WordPress: Tools → Site Health → Info → Server shows the PHP version the site runs on.
• Shared hosting: the PHP settings in your control panel, often labelled “Select PHP Version” or “MultiPHP Manager”.
• Your own server: php -v works, but the command line can use a different PHP binary from the web server. Check what the web server itself reports.

A version below the fixed releases, such as 8.4.26, normally means you are not patched. There is one important exception. Linux distributions such as Debian, Ubuntu and Red Hat often backport fixes into their own packages without changing the upstream version number, and the PHP team says distributions received these patches in advance. If your server uses distribution packages, check the distribution’s security notice or the package changelog rather than relying on the number alone.

If you cannot update PHP today

The PHP team is clear that only an update fixes the problem. Until it is in place, the advisory lists temporary measures that reduce exposure to the known attack paths without making an installation safe. The most practical ones are:

• Disable session.upload_progress.enabled in php.ini or the server configuration, then restart every PHP worker. Setting it through ini_set() or a .user.ini file does not work.
• Lower post_max_size: 8M if the site accepts no uploads, 32M if it does.
• Limit request size and field counts at the web server or proxy.

Some of the other measures, such as removing PHP’s memory limit, have side effects on stability and should only be applied by someone who knows the server. Treat all of them as a bridge to the update, not a substitute for it.

Updating your PHP version without breaking things

A patch release within the same branch, for example 8.4.26 to 8.4.27, contains security fixes and should not change how your code behaves. It is low risk and should happen now.

The real work is for anyone on PHP 8.1 or older. Jumping to 8.3 or 8.4 can break old plugins, themes or custom code. Take a backup, test on a copy of the site, watch the error log, and update plugins and themes before you switch PHP versions. Note too that PHP 8.2 only receives security fixes until 31 December 2026, so if you are on 8.2 it is time to plan the next step. If nobody on your team knows the codebase, a code audit shows what has to change before you upgrade.

Frequently asked questions

In practice

Check your PHP version today. If it is below the fixed releases, ask your host for the update or apply it yourself, then confirm the new version is the one actually serving the site. If you are on a version that is no longer supported, plan the upgrade now rather than waiting for the next critical vulnerability. For larger upgrades and rebuilds of legacy PHP systems, we can help through our web development and software development services.