PHP Vulnerability October 2026: CVE-2026-109618 and CVE-2026-109619 Explained, and What to Do Now

On 21 October 2026 the PHP project released emergency security updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. They can allow unauthenticated remote code execution: an attacker who can send a web request to your server may be able to run their own code on it, without logging in. The PHP team's advice is short: update now.

This guide explains, in plain language, who is affected, which versions fix the problem, how to check and update your own servers, and what to do if you cannot update today. Everything here is based on the official PHP announcements; check them for the latest details.

What happened, in plain words

PHP runs a large share of the web: WordPress, WooCommerce, Laravel, Drupal, Magento and countless custom business systems. The two bugs sit inside PHP itself, not in any one application, which is why they affect so many sites at once.

• CVE-2026-109618, "RCE via OOM corruption": when PHP runs out of memory at the wrong moment, request data can be left half set up, and the clean-up step may then treat the broken data as valid.
• CVE-2026-109619, "RCE via stale global state": internal data from one request can survive after its memory has been freed, and a later request handled by the same worker may use it before it is reset.

According to PHP, all PHP installations that serve web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The risk is highest for Apache with mod_php, where the PHP team says an exploit has been demonstrated in which an unauthenticated request triggers the attack before any of your application code runs. That means a well-written application does not protect you: the fix has to happen in PHP.

Which versions fix it

Your PHP branch	Update to at least	Notes
8.5	8.5.12	On 8.5 there is an extra temporary setting (see below).
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35	PHP 8.2 reaches end of life on 31 December 2026. Plan an upgrade.
8.1, 8.0, 7.4 and older	No official release	No longer supported. See old PHP versions.
8.6 test builds	8.6.0 RC4	Not for production.

Step 1: check which PHP version your site really uses

Many servers have more than one PHP version installed. The version you see on the command line is not always the one serving your website, so check the web one.

• Hosting control panel: in cPanel look for MultiPHP Manager or Select PHP Version; Plesk shows it under the domain's PHP Settings.
• WordPress: go to Tools → Site Health → Info → Server.
• Laravel or any PHP app: a temporary page with <?php phpinfo(); shows the exact version and which server API is in use (for example FPM/FastCGI or Apache 2.0 Handler, which is mod_php). Delete it right after.
• Command line: php -v, and for PHP-FPM php-fpm8.3 -v (use your version number).

Important: Linux distributions such as Ubuntu, Debian, Red Hat and their LTS vendors often fix security bugs without changing the main version number. PHP says distributions received the patches in advance. If your PHP comes from your distribution, check that vendor's security notice or package changelog for the two CVE numbers instead of comparing version numbers.

Step 2: update PHP

Shared or managed hosting

Your hosting company controls PHP. Many will patch automatically; ask your host to confirm that your PHP version includes the fixes for CVE-2026-109618 and CVE-2026-109619. If you are on PHP 8.1 or older, ask to move to a supported version (8.3 or 8.4 is a safe choice for most sites) and test your site afterwards.

Your own Ubuntu or Debian server

1. Install the updates: sudo apt update && sudo apt upgrade. If you use a third-party PHP repository, the same command pulls its new packages.
2. Restart PHP so the old processes stop: sudo systemctl restart php8.3-fpm (your version), or sudo systemctl restart apache2 if you use mod_php.
3. Check again (Step 1) and test the main pages, forms, logins and payments.

Red Hat, Rocky, AlmaLinux, CentOS Stream

Run sudo dnf upgrade (or the command for your PHP module or repository), then restart php-fpm or httpd and test.

Docker and containers

Updating the server is not enough: rebuild your images on a fixed PHP base image (for example a new php:8.3-fpm or php:8.4-apache build that includes 8.3.36 or 8.4.27), push them, redeploy, and make sure no old containers are still running.

Windows

Download the fixed build from the PHP downloads page, replace the old files, and restart IIS or your web server.

Whatever the setup, restart every PHP worker. Old PHP-FPM or Apache processes keep running the vulnerable code until they are restarted.

If you cannot update today

PHP is clear that only updating is a complete solution. The settings below reduce some attack paths but do not make a server safe. Apply them in php.ini, the FPM pool or the web server configuration, not with ini_set() or .user.ini, and restart every worker.

• For CVE-2026-109619: set session.upload_progress.enabled=0. On PHP 8.5, also set fatal_error_backtraces=0.
• For CVE-2026-109618: set memory_limit=-1 in a way applications cannot override (for example php_admin_value), and set a low post_max_size: 8M if you do not need uploads, 32M if you do, with upload_max_filesize below it. Use container or cgroup memory limits as a safety boundary, but do not use RLIMIT_AS or RLIMIT_DATA.
• Remove invalid or deprecated settings that make PHP print warnings at the start of each request, and fix errors and timeouts that an attacker could trigger. Hiding warnings does not help.

These settings can affect how your application works, especially uploads. Test them, and treat them as a short bridge to the real update.

Follow-up on 23 October: session upload progress

On 23 October PHP published an informational notice about a related, less likely issue (CVE-2026-115560). It only affects applications that change session.serialize_handler at runtime with ini_set() while session upload progress is enabled. PHP suggests keeping session.upload_progress.enabled=0 until the next regular bugfix release. If you already applied it on 21 October, leave it in place.

Running PHP 8.1, 8.0, 7.4 or older?

These versions no longer get updates from the PHP project, so there is no official fixed release. Because of the severity, the PHP security team published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves, and some Linux vendors and LTS providers offer backported packages. For most businesses the right answer is to upgrade to PHP 8.3 or 8.4. That usually means updating the framework, plugins and some code, so plan it rather than rushing it on a live site:

1. Copy the site to a staging server.
2. Switch staging to the new PHP version and run your tests, or click through the key pages if you have none.
3. Fix deprecated code, update Composer packages and plugins.
4. Switch production during a quiet hour, with a backup and a way back.

Quick checklist

1. List every server, site and container that runs PHP, including staging and old forgotten sites.
2. Check the PHP version and how it is installed (host, distribution package, Docker image, source).
3. Update to 8.5.12, 8.4.27, 8.3.36, 8.2.35 or your vendor's patched package.
4. Restart all PHP workers and web servers.
5. Confirm the version or patch, then test logins, forms, uploads and payments.
6. If you cannot update today, apply the temporary settings and set a date to finish.
7. Plan the move off PHP 8.1 or older, and off 8.2 before 31 December 2026.

How UnlockLive can help

We have built and maintained PHP, Laravel and WordPress systems since 2008. Our emergency PHP security update service checks every server you have, applies the fix the right way for your setup (hosting, VPS, cPanel or Docker), restarts everything, tests the site and sends you a short written report. If you are on an old PHP version, we can upgrade you safely on a staging copy first.

Not sure if you are affected? Send us your site address or book a free 30-minute call, and an engineer will tell you what to do.