Apache and PHP: patching mod_php today, moving to PHP-FPM next

Check first

Find out which one your server uses

Ask Apache which MPM and modules it has loaded. Debian and Ubuntu load mod_php under the name php_module.

# Debian and Ubuntu: the MPM Apache is using
a2query -M

# Loaded modules: php_module means mod_php, proxy_fcgi_module means FastCGI
sudo apache2ctl -M | grep -E 'php|proxy_fcgi'

# RHEL and its rebuilds
sudo httpd -M | grep -E 'php|proxy_fcgi'

A prefork MPM with php_module is mod_php. An event MPM with proxy_fcgi_module is PHP-FPM. On RHEL 8 and later, Apache runs PHP through PHP-FPM by default. A hosting control panel can also tell you, and so can the server API the site reports, explained on how to check your PHP version.

The longer-term change

Moving a site from mod_php to PHP-FPM

On Debian and Ubuntu the move takes a handful of commands, because the FPM package already ships the Apache configuration it needs. Stay on the PHP branch you run today so that only one thing changes, and test on a staging copy first if you have one.

Before you start: settings that live in Apache

php.net documents php_value, php_flag, php_admin_value and php_admin_flag as settings for PHP running as an Apache module. Search the Apache configuration and every .htaccess file for them and move each one: per-directory values into .user.ini files, which PHP reads only under CGI and FastCGI, and server-wide values into the FPM pool or php.ini.

# .htaccess under mod_php
php_flag display_errors off

; .user.ini in the same directory, read by PHP under FastCGI
display_errors = Off

PHP re-reads .user.ini files every 300 seconds by default, so allow five minutes before judging a change.

The switch

# 1. Install PHP-FPM for the branch you already run (Debian 13: 8.4)
sudo apt install php8.4-fpm

# 2. Swap mod_php and prefork for FastCGI and the event MPM
sudo a2dismod php8.4 mpm_prefork
sudo a2enmod mpm_event proxy_fcgi setenvif
sudo a2enconf php8.4-fpm

# 3. Check the configuration, then restart Apache
sudo apache2ctl configtest
sudo systemctl restart apache2

• Order matters. Debian's mod_php module file declares that it depends on prefork, and the event MPM's file declares a conflict with prefork, so mod_php and prefork go first.
• Debian's a2enmod asks for a restart, not a reload, after module changes, and Apache refuses to start with more than one MPM loaded. The configuration test catches most mistakes first.
• The enabled php8.4-fpm configuration sends files ending .php, .phar and .phtml to /run/php/php8.4-fpm.sock, and refuses requests for raw .phps source files.
• mod_php's php.ini changes do not follow you: PHP-FPM reads /etc/php/8.4/fpm/, not /etc/php/8.4/apache2/.

If you need to go back

sudo a2disconf php8.4-fpm
sudo a2dismod mpm_event
sudo a2enmod mpm_prefork php8.4
sudo systemctl restart apache2

Rolling back puts the site on mod_php again, so only do it on a patched build. On RHEL 8 and later there is usually nothing to move: PHP-FPM is already the default. Pools, restarts and running several branches are covered in the PHP-FPM guide.

Confirm it worked

Check what Apache is serving now

# Which PHP modules Apache has loaded now
sudo apache2ctl -M | grep -E 'php|proxy_fcgi'

# "Active: active (running) since" should be after your restart
systemctl status apache2

Then ask a page on the site. Upload this file, load it once and delete it straight away:

<?php
// sapi-check.php: open it once, then delete it from the server
echo phpversion(), ' via ', php_sapi_name();

• apache2handler means mod_php is still in use; fpm-fcgi means the move to PHP-FPM worked.
• Expect your branch's fixed release. On a distribution build, the package version from step 2 is the one to compare with the advisory.
• Check every virtual host that matters. A site with its own handler configuration can end up on a different PHP from its neighbours.

Since 26 October 2026 both vulnerabilities have been in CISA's Known Exploited Vulnerabilities catalogue. If this server was reachable while it ran a vulnerable mod_php, the update does not remove anything already left behind. Has your PHP site been compromised?