Critical PHP Security Vulnerabilities in October 2026: What Website Owners Need to Know

Most business websites run on PHP. WordPress, Laravel, Magento, Drupal, almost every custom booking system and admin panel built in the last fifteen years — all of it sits on a PHP runtime that someone, somewhere, has to keep updated.

On 21 October 2026 the PHP project released four versions at once to fix two vulnerabilities it rated as critical. If you own a website and you have not heard anything about it from whoever maintains your hosting, this article is the short version of what happened and what needs to be true of your server.

We are not going to explain how to exploit anything. The point here is the decision a business owner has to make, and the decision is not complicated: get onto a patched version, and verify it afterwards.

What was fixed

Two vulnerabilities were patched in the same change:

The release notes in each of the four releases carry the same single entry under Core: "Fixed GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp (Avoid state corruption via bailout). (CVE-2026-109618, CVE-2026-109619)". The upstream commit touches PHP's memory allocator, its executor, the multipart request parser (main/rfc1867.c), the session extension and OPcache — in other words, the engine itself rather than any one library you could simply stop using.

Both are described by the PHP project as critical and as allowing remote code execution without authentication. Security vendors and national CERTs that published their own advisories in the days afterwards have reported a CVSS v4.0 base score of 9.2 and exploitation in the wild, and the United States Cybersecurity and Infrastructure Security Agency added both identifiers to its Known Exploited Vulnerabilities catalogue on 26 October 2026. Those are third-party assessments rather than the PHP project's own wording, but they all point the same way: this is not one to defer.

"Remote code execution" is the part that matters commercially. It means an attacker can make your server run code of their choosing. From there, everything else your site can reach — the database, customer records, stored files, outbound mail — is reachable too.

Which PHP versions are safe

Four releases carry the fix:

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

All four are dated 22 October 2026 in their own NEWS files and were tagged on 21 October 2026. Anything older than its branch's patched version is affected. You can confirm the entries yourself in the release notes for PHP 8.4.27 and PHP 8.5.12, or in the project's own changelog.

There is no fix for PHP 8.1 or earlier. Those branches have reached end of life, so no patched release exists and none is coming. The supported versions page is the authoritative list of which branches still receive security fixes. If your application is on PHP 8.1, 8.0, 7.4 or earlier, updating the runtime is no longer a maintenance task you can schedule next quarter — it is the only route to a patched engine, and it needs a compatibility plan. We have written separately about when to modernise an existing PHP application.

Unofficial community backports to end-of-life branches have appeared on GitHub. We do not recommend running one on a production business website: you would be trusting an unreviewed patch to a security-critical code path, built by someone with no obligation to you, in place of a release the PHP project actually tested.

Why timely updates matter here specifically

Plenty of PHP security advisories affect a narrow configuration — one extension, one function, one build option. This pair does not. The affected code is the engine's own state handling, and the published advisories describe every PHP installation serving web requests as exposed, across the common ways PHP is deployed: PHP-FPM, Apache with mod_php, php-cgi, and the newer application servers.

That has two consequences for a business:

1. You cannot mitigate your way out of it in application code. There is no setting in WordPress or Laravel, no plugin, and no firewall rule that substitutes for a patched runtime. Interim mitigations circulated before the patch, including disabling session upload progress, were explicitly interim, and PHP contributors publicly cautioned that they were not complete. Updating is the fix.
2. The window between disclosure and exploitation is short. Both identifiers were in CISA's exploited-vulnerabilities catalogue within five days of the release. A patch that sits unapplied for a month is, in practice, not a patch.

How to check what you are running

Three ways, in order of how much access you need:

• Hosting control panel. cPanel, Plesk and most managed hosts show the active PHP version per domain, and that is also where you change it.
• Ask your host. "Which PHP patch release is my account running, and has it been updated for CVE-2026-109618?" is a reasonable support ticket, and the answer should be a specific version number, not "the latest".
• From the server. php -v on the command line, which tells you the CLI version — not necessarily the one your website uses. The web server's version is what counts, and a one-line script calling phpinfo() will show it. Delete that script immediately afterwards; leaving it reachable publishes your entire server configuration.

Be aware that the CLI version and the web version genuinely do differ on many shared hosts. We have seen servers where the command line reported a patched release while the site itself was still being served by an older one.

Updating a live site without breaking it

A patch release within the same branch — 8.4.26 to 8.4.27, say — is a low-risk update by design. PHP's branch policy means patch releases carry security and bug fixes, not language changes. In practice the update is usually uneventful. "Usually" is still not "always", so the sequence matters.

Take a backup first. Files and database, both, and verify you can actually read the backup before you touch anything. A backup you have never restored is a hypothesis.

Check compatibility if you are crossing a minor version. Moving from 8.3 to 8.4, or 8.4 to 8.5, is a different exercise from a patch update: deprecations and behaviour changes apply. The migration guides — 8.4, 8.5 — list them. Stay inside your current branch if you simply need the security fix today, and plan the minor upgrade as its own piece of work.

Update, then restart the right thing. Changing the PHP version is not live until the process serving your pages restarts. With PHP-FPM that is the FPM service, and the pool workers specifically; a config change with no reload is a config change with no effect.

Test the paths that touch PHP hardest. Not just the homepage. Log in. Submit the contact form and confirm the email arrives. Place a test order or booking through to the payment step. Upload a file. Open the admin area and save something. If you have a scheduled job that generates invoices or reports, run it manually. These are the places a version change shows up, and the homepage is the place it never does.

Then watch the logs. PHP error logs and the web server's error log, for a few days, not a few minutes. A deprecation warning that fires on one rarely-used page will not appear during a ten-minute test.

What this costs you if you have no maintenance arrangement

The technical work here is small. Finding out that it needed doing is the part that is easy to miss.

Two advisories were published on a Wednesday. Exploitation was being reported within days. Nobody emails a business owner to tell them their PHP version is now a liability. The sites that were patched quickly were the ones where somebody was already watching for this kind of thing — and the sites that were not are mostly still waiting for someone to notice.

That is the real argument for proactive maintenance, and it is not an argument about skill. It is about whether anyone is looking. We have written about what happens when someone is, and about what ongoing maintenance actually covers after a site goes live.

A note on what came next

If you are reading this some time after publication, check for newer advisories before you treat a patched version as current. Re-checked on 1 November 2026, when this article was last updated: PHP 8.4.27 and 8.5.12 are still the latest releases on their branches, and no newer release has superseded them.

Separately, a further session-handling vulnerability — CVE-2026-115560 — was disclosed after the October releases and is not fixed by them. From the published descriptions, it needs an unusual configuration to be exploitable: the session serializer set to php_binary or php_serialize in configuration and then changed to php at runtime before session_start(), with session upload progress still enabled. The PHP project has acknowledged it and a fix is expected in a future regular release; the interim mitigation being recommended is to set session.upload_progress.enabled = 0 in php.ini or the PHP-FPM pool configuration and restart the workers, rather than relying on an application-level ini_set() call, which can run too late. The session configuration reference documents that setting. Turning it off stops PHP's server-side upload progress feature, which very few sites use; browser-side upload progress bars are unaffected.

We are flagging it here rather than treating it as settled, because at the time of writing the authoritative advisory has not been published. Check php.net for the current state before acting on any summary of it, including this one.

The short version

• Two critical remote code execution flaws in PHP, patched on 21 October 2026.
• Safe versions: 8.5.12, 8.4.27, 8.3.36, 8.2.35.
• PHP 8.1 and earlier get no fix. If you are on one, the runtime upgrade is the work.
• Back up, update within your branch, restart the web process, then test logins, forms, payments and uploads — and read the logs for a few days afterwards.
• If nobody is currently responsible for watching for advisories on your site, that is the thing worth fixing, not just this one patch.