Two critical PHP vulnerabilities, fixed today. Check your servers.

This afternoon the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 on CVSS v4.0. Either one lets an attacker run code on the server from an ordinary web request, before any application code gets a say. The details leaked before the planned release time, so the fixes went out early and probing has already been seen in the wild. If you run anything on PHP, this is a today job, not a this-week job.

Who is affected

Every PHP installation that serves web requests: PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed alike. The PHP project rates mod_php the highest risk. It makes no difference whether the site is WordPress, Drupal, Magento, Laravel or something written in-house; the flaws are in PHP itself.

Check your version

Run php -v on each server, or look at the version your hosting panel reports, and compare with the first fixed release of your branch:

Anything older than the number on the right is exposed. PHP 8.1, 8.0 and 7.x no longer receive updates from the PHP project; some Linux distributions and long-term-support vendors backport fixes to the versions they ship, so check with yours, but the real answer for those is an upgrade to a supported branch. PHP 8.2 itself reaches end of life on 31 December 2026, so if you are patching 8.2 today, plan the move to 8.3 or 8.4 for the coming weeks.

If you cannot update today

The PHP project has published settings that narrow the attack paths. They are not a fix, and the project says so plainly: an installation with them applied is still vulnerable, just less reachable. Use them to buy hours, not weeks.

• Set session.upload_progress.enabled = 0 in php.ini or the FPM pool, then restart every worker. It has to apply before request parsing, so ini_set() and .user.ini do not count.
• Set memory_limit = -1 with a sensible post_max_size (8M, or 32M if you take uploads), preferably as php_admin_value so applications cannot override it. Do not substitute process limits such as RLIMIT_AS; those can trigger the vulnerable allocation failure instead of preventing it.
• On PHP 8.5, also set fatal_error_backtraces = 0 and restart the workers.

If you would rather someone did it for you

We patch, we upgrade, and we tell you what we found. If nobody on your side is free tonight, or you are not sure which versions you are running across your estate, write to hello@lambda-twelve.com or use the contact page and we will take it from there.

The authoritative source is the PHP project's own advisory on php.net.