PHP-FPM and PHP2Shell: Patch, Restart and Configure

As of 23 October 2026, PHP-FPM is affected by both PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619, and the fix is the same as everywhere else: install PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distribution's patched package, then restart the PHP-FPM service. PHP's own advisory lists PHP-FPM among "all PHP installations serving web requests" that are at risk.

PHP-FPM (FastCGI Process Manager) is the program that runs PHP behind nginx, Apache with mod_proxy_fcgi and most modern hosting stacks. It keeps a pool of PHP worker processes running and hands each request to one of them. Those workers load PHP once and keep it in memory. That is why installing the update is only half the job. Until the service restarts, the old, vulnerable code keeps serving your pages.

Below: what the advisories say about FPM, the service name for each Linux family, restart versus reload, pool-level mitigations and the PHP_VALUE check.

What the Advisories Say About PHP-FPM

PHP published one advisory per flaw. Both discuss FPM, and neither clears it.

• CVE-2026-109618 (out-of-memory corruption). The GHSA-w8hw advisory says: "Source analysis therefore supports FPM as a susceptible, though no complete FPM exploit has been demonstrated for this SAPI." (A SAPI is the interface that connects PHP to a web server. FPM, mod_php and php-cgi are all SAPIs.)
• CVE-2026-109619 (stale state between requests). The GHSA-6wmf advisory says "Session lifecycle RCE was validated against mod_php and FPM." It adds that this "works with a normal dynamic FPM pool, although it depends on a suitable application operation."

Some vendors describe FPM as harder to attack than mod_php. Red Hat, whose RHEL systems use FPM by default, says remote code execution "is difficult in practice and typically requires non-default behavior." That is useful context, not a reason to wait. The advisories still call updating the only complete fix. Our guide to Apache mod_php and PHP2Shell explains why mod_php sits at the top of the risk list.

Step 1: Find the FPM Service That Serves Your Site

Many servers run more than one PHP version side by side, each with its own FPM service. Patch and restart every version that serves websites, not just the one your command line uses. The service name depends on where your PHP came from.

On Debian and Ubuntu, the version in the service name is the PHP branch, such as 8.3. It is not the patch release. Replace 8.3 in every command below with the branch you actually run.

Step 2: Install the Fixed Packages

Use your distribution's normal update channel. Distributions backport the fix, which means they add the patch to the version they already ship. So the version number you see often stays below PHP's own release numbers.

• Ubuntu. Ubuntu's security notice USN-8948-1 says "a standard system update will make all the necessary changes." The fixed FPM package on 24.04 LTS is php8.3-fpm 8.3.6-0ubuntu0.24.04.13. It still reports PHP 8.3.6. Ubuntu documents the update as sudo apt update && sudo apt upgrade.
• Debian. Fixed builds include php8.4 8.4.27-1~deb13u1 on trixie and php8.2 8.2.35-1~deb12u1 on bookworm.
• AlmaLinux. The AlmaLinux PHP2Shell post gives sudo dnf clean metadata && sudo dnf upgrade 'php*', then checking the result with rpm -q php-common. It warns: "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change."
• cPanel and CloudLinux. CloudLinux documents dnf clean all && dnf upgrade "ea-php*" on CloudLinux 8, 9 and 10 (yum on CloudLinux 7). It also says: "update each one that serves websites, then restart PHP-FPM or the web server so the new build is loaded."

For every branch and distro build number, see our PHP2Shell fixed versions table. If you run PHP 8.1 or older, there is no official PHP release. You need a vendor backport or an upgrade.

Step 3: Restart PHP-FPM, Not Just Reload

This is the step people skip. The workers that were running before the update still hold the old code in memory. Restart the service:

sudo systemctl restart php8.3-fpm (Debian and Ubuntu; replace 8.3 with your version)
sudo systemctl restart php-fpm (RHEL, AlmaLinux, Fedora)

Before restarting, you can test the configuration so a typo doesn't take the site down. The PHP-FPM man page documents -t: "Test FPM configuration file and exit." On Debian and Ubuntu the binary carries the version, so the test is sudo php-fpm8.3 -t (replace 8.3 with your version). On RHEL-family systems it is sudo php-fpm -t.

What about systemctl reload?

The man page lists the signals FPM accepts. SIGUSR2 means "graceful reload of all workers + reload of fpm conf/binary," and the systemd unit files from PHP, Debian and Fedora all map systemctl reload to that signal. So by the documentation, a reload also loads the new binary.

The vendor instructions still say restart. PHP says "restart every worker." php2shell.com says "restart Apache, PHP-FPM and any long-running PHP workers." CloudLinux says "restart PHP-FPM or the web server so the new build is loaded." For a critical security fix, follow the vendors: do a full restart, then confirm it happened. A restart stops all workers, so requests in progress at that moment can fail. Pick a quiet minute if you can, but don't wait long.

Also restart anything else that runs PHP for a long time, such as queue workers or scheduled job runners. Our guide to restarting PHP workers after a security update has the commands for every setup and how to check that the restart took place.

Step 4: Confirm the Fix Is Live

The command-line php -v can report a different PHP from the one FPM runs, and backported builds keep old version numbers. Check it three ways:

1. Package version. Compare the installed FPM package, such as php8.3-fpm on Ubuntu or php-common on AlmaLinux, with the fixed version in your distribution's advisory. Debian's security FAQ also points to the package changelog: apt-get changelog followed by the package name.
2. What the website sees. A temporary phpinfo() page shows the PHP that actually served the request, including the Server API line. Delete it straight away.
3. Service start time. systemctl status php8.3-fpm (replace 8.3 with your version) shows when the service last started. It should be after the package update.

Our guide on how to check your PHP version walks through each method and how to read backported version numbers.

Pool-Level Mitigations If You Can't Patch Yet

An FPM pool is a group of workers with its own configuration file, often one pool per site. Pool files are one of the places where PHP's interim mitigations actually work. PHP's advisory says to use "php.ini, an FPM pool or server configuration that applies before request parsing. Do not rely on ini_set() or FPM .user.ini."

Use php_admin_value rather than php_value. The PHP-FPM configuration manual says "Settings defined with php_admin_value and php_admin_flag cannot be overridden with ini_set()." Example pool lines (AlmaLinux documents the memory_limit line in its PHP2Shell post):

php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[memory_limit] = -1

Two cautions. First, memory_limit = -1 removes PHP's memory cap. Pair it with a container or cgroup limit, never RLIMIT_AS or RLIMIT_DATA, and check that nothing puts a finite limit back. Second, every pool needs its own lines. Restart FPM after any change.

The CVE-2026-109619 advisory also suggests pm.max_requests=1, which recycles each worker after one request, "if performance is not a factor." Fastly calls the performance cost severe. Treat it as a last resort.

These settings reduce exposure. They do not fix the flaws. What each one blocks and breaks is covered in our PHP2Shell interim mitigations guide.

The PHP_VALUE Check: An FPM-Specific Condition

Web servers can pass PHP settings to FPM with each request, using the FastCGI parameters PHP_VALUE and PHP_ADMIN_VALUE. In nginx these appear as fastcgi_param PHP_VALUE lines. PHP's CVE-2026-109619 advisory names this as the condition that exposes FPM to one of the confirmed paths:

"FPM is conditionally exposed when nginx, Apache mod_proxy_fcgi or another frontend sends PHP_VALUE / PHP_ADMIN_VALUE parameters that produce a diagnostic before request initialization."

A diagnostic here means a warning, notice or deprecation message, for example from a setting that is misspelled or no longer exists. The advisory's remediation is: "Eliminate diagnostics from all INI configuration applied before request initialization. Prefer php.ini, FPM pool or server configuration applied at startup over per request overrides, and remove obsolete directives."

In practice:

1. Search your web server configuration for PHP_VALUE and PHP_ADMIN_VALUE.
2. Remove any directive that is obsolete, invalid or misspelled.
3. Move the settings you still need into php.ini or the pool file.
4. Restart the web server and FPM.

Hiding the warning does not help. PHP's advisory says changing error_reporting, using @ or disabling display_errors or log_errors "does not protect against this vulnerability." The nginx side of this, including request size limits, is covered in our nginx with PHP-FPM guide.

Containers and Control Panels

Docker. The official php:*-fpm images were rebuilt with fixed PHP on 21 October: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The 8.1 and 7.4 tags have not been rebuilt. Updating the host does not update PHP inside an image. Pull or rebuild the image, then replace the running containers. Docker Hub also warns that the FastCGI protocol "is inherently trusting" and that the FPM image should not be published outside a private container network. Check that your FPM port is not reachable from the internet.

Control panels. On cPanel, Plesk and similar panels, the panel vendor builds PHP and the host usually applies it. Your job is to confirm that the build serving your site is patched and that FPM restarted. Who handles what depends on your hosting plan. Our shared responsibility model guide explains the split. For a general patch routine you can reuse after this, see our security patching best practices.

Conclusion

As of 23 October 2026, PHP-FPM needs the same fix as every other PHP setup: a patched PHP build, then a full restart of every FPM service that serves websites. Use the right service name for your distro, test the configuration first, and confirm that the build serving pages is the patched one. If you can't patch today, put mitigations in the pool file with php_admin_value and clean up any PHP_VALUE lines your web server sends. If you'd rather have someone patch, restart and verify for you, our emergency PHP patching team can help. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions