In short: All common operating modes are affected by PHP2Shell, but with Apache and mod_php the PHP team rates the risk highest. An exploit was demonstrated there before any application code even runs. If you operate mod_php, you should update PHP first and fully restart Apache.
What is mod_php?
With mod_php, PHP is a module inside the Apache web server. Every Apache process contains a complete PHP interpreter and executes PHP code directly. This operating mode was the standard for a long time and is still widespread on older servers, in many distribution packages and in some Docker images.
The alternative is PHP-FPM: there PHP runs as a separate service with its own processes, and Apache or Nginx merely passes requests on. Both variants are affected by PHP2Shell, as are php-cgi, FrankenPHP and LiteSpeed.
Typical environments with mod_php are older root servers that have been running unchanged for years, standard Apache installations from distribution packages and Docker images with Apache and PHP in one container. If you do not know for sure which operating mode your server uses, you should check instead of assuming.
Why is the mod_php vulnerability considered particularly risky?
The PHP team has given a clear assessment of PHP2Shell: with mod_php, the risk is highest. The reasoning: an exploit was demonstrated there that takes effect before any application code even runs.
For operators, this has an uncomfortable consequence. Many protective measures sit in the application: security plugins in WordPress, firewall modules in shops, checks in custom code. All of these are application code. If exploitation happens before them, they come too late.
Added to this is the tight coupling: with mod_php, PHP shares the process with Apache. Whatever compromises PHP runs with the rights of the web server and in its memory. With PHP-FPM, by contrast, pools can be separated with their own users per website, which can limit the consequences of a break-in.
For prioritisation this means: if you operate several servers, those with mod_php come first, and for them a subsequent check for traces is particularly important.
What we do not know: how many of the 22.6 million exposed, potentially vulnerable instances counted worldwide use mod_php. Reliable figures on this have not been published.
Does my server use mod_php?
The following commands are read-only. Service and command names differ by distribution: Debian and Ubuntu use apache2, the RHEL family httpd.
apachectl -M 2>/dev/null | grep -i php # e.g. php_module or php8_module
httpd -M 2>/dev/null | grep -i php # RHEL, AlmaLinux, Rocky
a2query -m | grep -i php # Debian/Ubuntu
apt policy libapache2-mod-php8.3 # Debian/Ubuntu, package version of the module
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL family
If no PHP module appears, Apache is probably using PHP-FPM via proxy_fcgi. In that case the notes at Securing Nginx with PHP-FPM apply analogously.
What mod_php operators should do now
- Update the PHP module to 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or a confirmed backport from your distribution.
- Fully restart Apache, not just reload it. With mod_php, the old PHP code sits in every Apache process.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL family
ps -o pid,lstart,cmd -C apache2 # check the start time, on RHEL: -C httpd
- Apply interim measures if the update is not yet possible. php.net names, among other things, fixed limits that applications cannot override:
# server configuration or VirtualHost, not .htaccess
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
With memory_limit=-1, a memory limit via cgroup is part of the setup, not via RLIMIT_AS or RLIMIT_DATA. These measures are not full protection; the details are at Immediate measures if you cannot patch yet. If neither is possible right away, the BSI (German Federal Office for Information Security) recommends taking the web server off the network temporarily.
If your Apache with mod_php was exposed to the internet without protection between 17 October and the patch, preserve the logs from 20 October onwards and have the server checked for traces. The patch alone does not prove that nothing happened.
In the medium term: moving away from mod_php
After the patch, it is worth looking at the architecture. Moving to PHP-FPM with Apache mpm_event and proxy_fcgi, or with Nginx, separates PHP from the web server, allows separate pools and users per website and makes restarts and version changes easier. It does not close PHP2Shell, but it reduces the attack surface for future vulnerabilities.
The switch needs planning. Settings that were previously set via php_value in .htaccess no longer take effect under PHP-FPM and have to move into the pool. Users and permissions change, and upload and cache directories may need new permissions. In a test environment this is well manageable; in live operation under time pressure it is not. Notes on the switch can be found at Securing Apache with mod_php.
How does PHP SOS help?
- Detect: We check which servers use mod_php and which package source the module comes from.
- Patch and restart: Through the PHP patch service, we install the update and verify that no old Apache process is still running.
- Secure the transition: Where the update is blocked, we apply the php.net measures in the server configuration.
- Switch over: As part of server hardening, we plan and test the move to PHP-FPM with separate pools.
Frequently asked questions
How do I know whether my Apache uses mod_php?
With apachectl -M or httpd -M you see the loaded modules. If a module such as php_module or php8_module is listed, PHP runs directly inside Apache. On Debian and Ubuntu, a2query -m also shows whether a php module is active.
Does a security plugin in WordPress protect me with mod_php?
Not against this vulnerability. According to the PHP team, an exploit was demonstrated with mod_php before any application code even runs. A plugin is application code and therefore comes too late. Only the PHP update with a restart of Apache protects you.
Should I switch from mod_php to PHP-FPM now?
Patch first, then switch. Moving to PHP-FPM makes sense in the medium term for most setups, because PHP then runs separately from the web server. It does not close PHP2Shell, though, because PHP-FPM is affected as well.