PHP2Shell: patch CVE-2026-109618 and CVE-2026-109619

On 21 October 2026 the PHP project released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. They are also referred to as PHP2Shell. According to the PHP project, they "can allow unauthenticated remote code execution": someone who can send a web request to your server may be able to run their own code on it, without an account. Both are rated 9.2 (CVSS v4.0).

The PHP project's advice is to update right away. There is no setting that fully protects you.

What the two vulnerabilities are#

The PHP security advisories describe them like this:

• CVE-2026-109618, "RCE via OOM corruption": when PHP runs out of memory while it is still setting up a request, the clean-up afterwards can treat half-prepared data as valid.
• CVE-2026-109619, "RCE via stale global state": data that belongs to one request can outlive it. A later request handled by the same PHP worker can then use memory that has already been freed.

The full technical details are in the advisories on GitHub: GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp in the php/php-src repository.

Who is affected#

Every PHP installation that serves web requests, with any PHP version older than the fixed releases. The PHP project names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php, where an attack was shown to work before any code of your website runs.

This includes:

• websites and web apps on your own server (WordPress, Laravel, Nextcloud and anything else written in PHP);
• the Pterodactyl Panel, which runs on PHP. Wings is written in Go and is not PHP, but the panel server is;
• PHP inside Docker containers;
• shared hosting and servers with a control panel such as DirectAdmin, cPanel or Plesk.

The advisories are about PHP handling web requests. They say nothing about PHP on the command line, but the command-line package comes from the same source, so update it along with the rest.

Which versions are fixed#

PHP 8.2 receives security fixes only until 31 December 2026. For PHP 8.1, 8.0 and 7.4, the PHP project published source patches for people who build PHP themselves, and some Linux distributions and long-term support vendors patch their own packages. Otherwise, move to a supported branch.

Linux distributions often keep their own version number and add the fix to it. The version you see is then lower than the table, while the package is patched. Compare against your distribution:

Ubuntu 20.04 and older have fixes only through Ubuntu Pro. For other distributions, look up the CVE number in your distribution's security tracker.

Check which PHP you run#

The command line and PHP-FPM are separate programs and can have different versions. Check both.

1. The command line:

   Copy

   php -v
   

2. PHP-FPM. On Debian and Ubuntu the program is called php-fpm followed by the branch:

   Copy

   ls /usr/sbin/php-fpm*
   /usr/sbin/php-fpm8.3 -v
   

3. On Debian and Ubuntu, check the installed package versions. This is what you compare with the distribution table above:

   Copy

   dpkg -l 'php*' | grep '^ii'
   

4. Check that the running PHP-FPM was restarted after the update. A patched package does not help while the old program is still running:

   Copy

   systemctl status php8.3-fpm
   

   The Active line shows since when it runs. It must be later than the moment you installed the update.

Run this for every PHP branch you have installed. Many servers have more than one.

Update PHP#

How you update depends on where your PHP comes from.

• Ubuntu or Debian packages, Ondřej Surý's PPA or packages.sury.org: update all PHP packages and restart PHP-FPM. The steps are in update PHP on Ubuntu or Debian. On 21 October 2026 packages.sury.org already had 8.5.12, 8.4.27, 8.3.36 and 8.2.35 for current Debian and Ubuntu releases.
• Docker: pull or rebuild the image and recreate the container. See update PHP in Docker images.
• A control panel such as DirectAdmin, cPanel or Plesk: PHP is installed by the panel. Use the panel's own update for PHP, or on shared hosting ask your hosting provider when they update.
• Rocky Linux, AlmaLinux or RHEL with the remirepo repository: the PHP project warned that remirepo would not have updates on release day, and advises switching to distribution packages or building from source.
• Built from source: build 8.5.12, 8.4.27, 8.3.36 or 8.2.35 from php.net.

After the update, restart every PHP-FPM service and Apache (if it uses mod_php), then check the versions again.

If you cannot update yet#

The PHP project lists measures that reduce the risk of known attack paths. They do not make a server safe. Use them only until you can update, and update as soon as you can.

Turn off session upload progress#

This blocks the confirmed attack path of CVE-2026-109619 through sessions. Most sites do not use this feature.

1. Find the ini folder of PHP-FPM. On Debian and Ubuntu it is /etc/php/<branch>/fpm/conf.d/.

2. Create a small file there, for example for PHP 8.3:

   Copy

   echo 'session.upload_progress.enabled = 0' | sudo tee /etc/php/8.3/fpm/conf.d/99-emergency.ini
   

3. Restart PHP-FPM, so every worker reads it:

   Copy

   sudo systemctl restart php8.3-fpm
   

4. If you use Apache with mod_php, put the same line in /etc/php/8.3/apache2/conf.d/99-emergency.ini and restart Apache with sudo systemctl restart apache2.

Set it in php.ini, a file in conf.d, a PHP-FPM pool or the web server configuration. Setting it from your application with ini_set() or in a .user.ini file does not work, because it must apply before PHP reads the request.

Other measures from the PHP advisory#

• On PHP 8.5: also set fatal_error_backtraces = 0 in the same way and restart.
• Keep request sizes low: set post_max_size = 8M for sites without file uploads, or 32M if you need uploads, with upload_max_filesize below post_max_size.
• Memory limit: the advisory describes memory_limit = -1 (set with php_admin_value in the FPM pool so applications cannot change it) as a measure for CVE-2026-109618, together with a container or cgroup memory limit. Without such a limit, one request can use all memory of the server, so read the advisory before you use this.

After updating, check for a break-in#

If your server ran a vulnerable PHP version on the internet, check whether someone got in before you updated. See check your server for a break-in.