The October 2026 PHP vulnerabilities: what you can patch, what you cannot, and what to do this week

Published 23 October 2026 · keepPhpUp · Sources: PHP advisories GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, php.net release of 21 October, Rapid7, watchTowr, Laravel Forge

If your application runs on a PHP version older than 8.2, this page is written for you. It is factual, it does not require you to be a developer, and it ends with the three things to do.

What happened

On 21 October 2026 the PHP project published fixes for two critical bugs, CVE-2026-109618 and CVE-2026-109619. Both let an attacker run code on the server without logging in, both are rated 9.2 out of 10, and both affect every PHP that serves web pages, however it is run: PHP-FPM, Apache with mod_php, php-cgi, LiteSpeed, FrankenPHP. Public proof-of-concept exploits exist and exploitation attempts have been seen in the wild since the day of the release.

In plain terms: the first bug is triggered by a specially crafted form or upload request that makes PHP run out of memory while it is still setting up, leaving things half built. The second lets leftover data from one request affect the next request handled by the same worker process. Neither needs a password, a user account, or a bug in your application code.

Who got a fix

The versions in the second and third rows together run roughly four in ten PHP sites on the public internet. If yours is one of them, your developer cannot "just update PHP". That option does not exist.

Can we reduce the risk without upgrading?

Partly, and only as a stopgap. The PHP project and security vendors list settings that close the known paths in. They do not make an unpatched PHP safe, and they do nothing for the next vulnerability.

• Turn off the session upload-progress feature, which is on by default and almost never used. One line in the server configuration.
• Bound the size of requests with post_max_size and, counter-intuitively, remove the per-request memory limit administratively so the memory failure that corrupts state cannot happen mid-setup.
• If the application has no file uploads or multipart forms, block that kind of request at the web server before it reaches PHP.
• If a web application firewall or Cloudflare sits in front, enable its rule for these two CVE numbers.

What to do this week

1. Find out what you are actually running. Not what the last developer said. Our free read-only check is a script you or your host run on the server; it reports the version, how PHP is served, and whether a patched package exists for you. It changes nothing.
2. Apply what can be applied. A package update if you are on 8.2 or newer. Otherwise the stopgap settings above, applied by someone who can also verify them.
3. Get a date for the real fix. Moving to a supported PHP version is the only durable answer, and for an application on 7.x it usually means framework work as well. A one-week assessment tells you what breaks, what it costs, and how long it takes, before you commit to anything.