Check the PHP-FPM version that is actually running

The PHP CLI version tells you nothing certain about PHP-FPM. They are separate binaries, often from separate packages, and the FPM process may have started months before the last update. For PHP2Shell (CVE-2026-109618 and CVE-2026-109619, disclosed 21 October 2026) you need the version of the code that is running in memory and serving requests.

This guide walks from the web server config to the socket, to the process, to the binary on disk, and finally to proof that the workers were replaced.

Prerequisites and applicable environments {#prerequisites}

• Root or sudo on the host.
• Nginx or Apache that proxies to PHP-FPM, or a standalone FPM listener.
• Knowledge of the distro family. Commands below are labeled for Debian and Ubuntu, and for RHEL, AlmaLinux, and Rocky Linux.

The guide does not cover mod_php. For that, see the Apache mod_php check. FPM is not safe from PHP2Shell. It is a different evidence level from internet-facing mod_php, and it still needs the fixed build.

How the pieces connect {#how-it-connects}

Step-by-step procedure {#procedure}

Step 1. Check the service state {#step-systemctl}

READ-ONLY

Debian and Ubuntu (unit names include the branch, such as php8.3-fpm):

systemctl list-units --type=service | grep -i 'php.*fpm'
systemctl status php8.3-fpm --no-pager

RHEL, AlmaLinux, Rocky Linux (the unit is php-fpm, or a stream-specific name on some builds):

systemctl list-units --type=service | grep -i 'php.*fpm'
systemctl status php-fpm --no-pager

Note the Active: ... since line. A date earlier than your update is already a warning sign.

Step 2. List FPM processes with start times {#step-ps}

READ-ONLY

ps -eo pid,ppid,lstart,args | grep -E '[p]hp-fpm|[p]hp.*fpm'

The master process is the one with the config path in its title and a parent PID of 1 (or the init system). The lstart column is the process start time. A master that predates the package update is still the old code, even if the file on disk is new.

Step 3. Find the listening socket {#step-ss}

READ-ONLY

sudo ss -xlpn | grep -i fpm
sudo ss -tlnp | grep -i fpm

The first command lists Unix sockets. The second lists TCP listeners, for pools that use 127.0.0.1:9000 or similar.

The pid= field names the process that owns the socket. That PID should match the master from Step 2.

Step 4. Ask the binary behind the process {#step-proc-exe}

READ-ONLY

sudo ls -l /proc/1042/exe

If there is no (deleted) marker, ask that exact binary for its version:

READ-ONLY

sudo /usr/sbin/php-fpm8.3 -v
sudo /usr/sbin/php-fpm8.3 -t

-v prints the version of the file on disk. -t tests the configuration and does not start the service. Use the full path from /proc/PID/exe, not a bare php-fpm.

Step 5. Map the package {#step-package}

READ-ONLY

Debian and Ubuntu:

dpkg -S /usr/sbin/php-fpm8.3
dpkg-query -W -f='${Package}\t${Version}\n' php8.3-fpm

RHEL, AlmaLinux, Rocky Linux:

rpm -qf /usr/sbin/php-fpm
rpm -q php-fpm

Compare the package version with the vendor advisory. On Ubuntu 24.04 noble, php8.3-* at 8.3.6-0ubuntu0.24.04.13 is the fixed build (USN-8948-1), even though the upstream base reads 8.3.6.

Map Nginx to the right pool {#nginx-mapping}

A host may run several pools and several branches. Find which one a given site uses.

Step 6. Read the Nginx config {#step-nginx-config}

READ-ONLY

sudo nginx -T 2>/dev/null | grep -nE 'server_name|fastcgi_pass'

Step 7. Match the target to the socket {#step-match}

For Apache with proxy_fcgi, look for SetHandler "proxy:unix:..." or ProxyPassMatch lines:

READ-ONLY

Debian and Ubuntu:

sudo apachectl -S 2>/dev/null | head -n 30
sudo grep -RInE 'proxy:unix|proxy:fcgi|SetHandler' /etc/apache2/

RHEL, AlmaLinux, Rocky Linux:

sudo httpd -S 2>/dev/null | head -n 30
sudo grep -RInE 'proxy:unix|proxy:fcgi|SetHandler' /etc/httpd/

Each pool has its own socket or port. Inventory every pool file under /etc/php/*/fpm/pool.d/ (Debian family) or /etc/php-fpm.d/ (RHEL family), because a pool can run under a different master than the one you checked first.

Prove the workers were replaced {#prove-replacement}

Updating the package is not enough. Confirm that the old master is gone.

CONFIG

Test the configuration before you restart:

sudo /usr/sbin/php-fpm8.3 -t

SERVICE

Restart during a window you have approved. A restart drops in-flight requests. A reload (systemctl reload) can leave the old master in place on some setups, so use a restart for a security update. See restart PHP-FPM safely.

Debian and Ubuntu:

sudo systemctl restart php8.3-fpm

RHEL, AlmaLinux, Rocky Linux:

sudo systemctl restart php-fpm

READ-ONLY

Then re-run Steps 2 to 4:

ps -eo pid,ppid,lstart,args | grep -E '[p]hp-fpm'
sudo ls -l /proc/$(pgrep -o -f 'php-fpm: master')/exe

Decision table {#decision-table}

Troubleshooting {#troubleshooting}

Completion checklist {#completion-checklist}

• Every FPM unit on the host is listed with its start time.
• Each web server fastcgi_pass or proxy_fcgi target is mapped to a socket and PID.
• /proc/PID/exe was read for every FPM master, and no target shows (deleted).
• The binary was queried by full path with -v, not through a bare php-fpm name.
• Package version matches the vendor advisory or a fixed upstream release.
• Configuration tested with php-fpm -t before the restart.
• Service restarted, and the new master start time is after the update.
• Every pool file is accounted for, including pools on other branches.
• Results recorded in the ticket with real hostnames, PIDs, and start times.

Related guides {#related-guides}

• Nginx with PHP-FPM
• Apache with PHP-FPM
• Restart PHP-FPM safely
• Check the installed PHP version
• Verify the patch after upgrade
• PHP2Shell risk assessment