Securing Apache with mod_php

In short: With Apache and mod_php, PHP runs directly inside the web server. The PHP team rates the risk from PHP2Shell highest in exactly this operating mode, because an exploit was demonstrated before any application code even runs. Patch immediately, restart Apache completely and then plan the move to PHP-FPM.

What mod_php is and why it matters now

With mod_php, Apache loads PHP as a module into each of its own worker processes. Every request for a PHP file is executed directly in that process. For a long time this was the standard, and it is easy to set up. But it also means: all websites on the server run as the same user, and PHP shares the process with the web server.

PHP2Shell covers the vulnerabilities CVE-2026-109618 and CVE-2026-109619, both with CVSS v4.0 9.2. With the second one, internal state of a request can persist after memory has been freed and be used by a later request in the same process. For mod_php, the PHP team has determined the highest risk. Background and context are under Why mod_php carries the highest risk.

Identifying Apache mod_php and checking the version

First check whether your Apache uses mod_php at all. The following commands only read. Command and package names differ by distribution and are examples.

# Debian/Ubuntu: loaded modules
apache2ctl -M 2>/dev/null | grep -i php

# RHEL family
httpd -M 2>/dev/null | grep -i php

# Which MPM is active? mod_php requires prefork
apache2ctl -V 2>/dev/null | grep -i mpm

# Package state of the module (examples)
dpkg -l | grep libapache2-mod-php
rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common'

If a module such as php_module appears, mod_php is running. The displayed PHP version alone is no proof of the patch, because distributions often apply fixes as a backport. The fixed versions from the PHP project are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. For distribution packages, the changelog with the CVE numbers is what counts.

Patch and restart Apache completely

Apply the update through the package manager. Because PHP sits inside the Apache process, the whole service must restart afterwards. Reloading the configuration is not the safe route here.

# Debian/Ubuntu
systemctl restart apache2

# RHEL family
systemctl restart httpd

# Check: start time of all Apache processes
ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep

All Apache processes must show a start time after the update. If PHP-FPM or php-cgi also runs on the same server, restart those services too.

Interim measures in the Apache configuration

php.net names interim measures that reduce the risk but do not offer complete protection. With mod_php, you set the values with php_admin_value or php_admin_flag in the Apache configuration, so that .htaccess and applications cannot override them.

# Example: in the VirtualHost or server-wide configuration
<IfModule php_module>
    php_admin_flag  session.upload_progress.enabled off
    php_admin_value post_max_size 8M
    php_admin_value upload_max_filesize 6M
</IfModule>

With an upload function, php.net gives post_max_size = 32M, with upload_max_filesize below it. On PHP 8.5, fatal_error_backtraces=0 is added. Implement the note on memory_limit=-1 only together with a memory limit for the service through cgroups, for example via MemoryMax in a systemd drop-in, not through RLIMIT_AS or RLIMIT_DATA. Then restart Apache completely. All measures at a glance: Immediate measures without a patch.

The way away from mod_php

After the acute patch, the move to PHP-FPM is worthwhile. There, PHP runs in its own processes, separate from the web server. Each website can get its own pool with its own user, limits can be set per pool, and restarts affect only PHP. Apache connects to PHP-FPM through mod_proxy_fcgi and can then use a more modern MPM such as event instead of prefork.

Plan the switch in a test environment: create pools per website, adjust file permissions for the new users, move .htaccess entries with php_value into pool settings, run load tests. What a clean setup looks like is shown in Securing Nginx with PHP-FPM; the principles apply equally to Apache with PHP-FPM.

Regardless of the operating mode: a patch does not remove malware that has already been planted. Keep the logs from 20 October 2026 onward and check the server for traces.

When searching for traces on mod_php servers, take a look at the shared user. Because all websites run under the Apache user, such as www-data or apache, an attacker who has taken over one website can generally also read and modify the files of the others. So do not check only the website that looks suspicious to you, but all document roots on the server. Pay particular attention to PHP files with a recent modification date in upload and cache directories, to program code owned by the Apache user, and to unknown entries in that user's crontab. If you find something, preserve the state first and do not delete hastily, so that the cause can still be traced later.

How does PHP SOS help?

• We check operating mode, MPM and package state and assess whether your server is actually patched.
• Through the PHP patch service, we apply the update, restart Apache completely and document the evidence.
• Until the patch, we set the interim measures so they cannot be overridden and limit memory at the service level.
• As part of server hardening, we plan and test the move to PHP-FPM with separate pools.

Frequently asked questions

Sources

• php.net: Security announcements
• PHP 8 ChangeLog
• BSI (German Federal Office for Information Security)
• OWASP Cheat Sheets