Kurz gesagt: Von PHP2Shell sind alle gängigen Betriebsarten betroffen, doch bei Apache mit mod_php stuft das PHP-Team das Risiko am höchsten ein. Dort wurde ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Wer mod_php betreibt, sollte PHP zuerst aktualisieren und Apache vollständig neu starten.
Was ist mod_php?
Bei mod_php ist PHP ein Modul innerhalb des Apache-Webservers. Jeder Apache-Prozess enthält einen vollständigen PHP-Interpreter und führt PHP-Code direkt aus. Diese Betriebsart war lange der Standard und ist auf älteren Servern, in vielen Distributionspaketen und in manchen Docker-Images bis heute verbreitet.
Die Alternative ist PHP-FPM: Dort läuft PHP als eigener Dienst mit eigenen Prozessen, und Apache oder Nginx reicht Anfragen nur weiter. Beide Varianten sind von PHP2Shell betroffen, ebenso php-cgi, FrankenPHP und LiteSpeed.
Typische Umgebungen mit mod_php sind ältere Root-Server, die seit Jahren unverändert laufen, Standardinstallationen von Apache aus Distributionspaketen und Docker-Images mit Apache und PHP in einem Container. Wer nicht sicher weiss, welche Betriebsart sein Server nutzt, sollte es prüfen, statt es anzunehmen.
Warum gilt die mod_php-Sicherheitslücke als besonders riskant?
Das PHP-Team hat zu PHP2Shell eine klare Einschätzung abgegeben: Bei mod_php ist das Risiko am höchsten. Begründung: Dort wurde ein Exploit gezeigt, der greift, bevor überhaupt Anwendungscode läuft.
Für Betreiber hat das eine unbequeme Konsequenz. Viele Schutzmassnahmen sitzen in der Anwendung: Sicherheits-Plugins in WordPress, Firewall-Module in Shops, Prüfungen im eigenen Code. Sie alle sind Anwendungscode. Wenn die Ausnutzung davor stattfindet, kommen sie zu spät.
Hinzu kommt die enge Verzahnung: Bei mod_php teilt sich PHP den Prozess mit Apache. Was PHP kompromittiert, läuft mit den Rechten des Webservers und in dessen Speicher. Bei PHP-FPM lassen sich Pools dagegen mit eigenen Benutzern je Website trennen, was die Folgen eines Einbruchs begrenzen kann.
Für die Priorisierung heisst das: Betreiben Sie mehrere Server, kommen die mit mod_php zuerst an die Reihe, und bei ihnen ist eine anschliessende Prüfung auf Spuren besonders wichtig.
Was wir nicht wissen: wie viele der weltweit gezählten 22,6 Millionen exponierten, potenziell verwundbaren Instanzen mod_php nutzen. Belastbare Zahlen dazu sind nicht veröffentlicht.
Nutzt mein Server mod_php?
Die folgenden Befehle sind rein lesend. Dienst- und Befehlsnamen weichen je Distribution ab: Debian und Ubuntu nutzen apache2, die RHEL-Familie httpd.
apachectl -M 2>/dev/null | grep -i php # z. B. php_module oder 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, Paketstand des Moduls
rpm -q --changelog php | grep -i -E "CVE-2026-109618|CVE-2026-109619" # RHEL-Familie
Taucht kein PHP-Modul auf, nutzt Apache wahrscheinlich PHP-FPM über proxy_fcgi. Dann gelten die Hinweise unter Nginx mit PHP-FPM absichern sinngemäss.
Was mod_php-Betreiber jetzt tun sollten
- PHP-Modul aktualisieren auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder einen bestätigten Backport Ihrer Distribution.
- Apache vollständig neu starten, nicht nur neu laden. Bei mod_php steckt der alte PHP-Code in jedem Apache-Prozess.
sudo systemctl restart apache2 # Debian/Ubuntu
sudo systemctl restart httpd # RHEL-Familie
ps -o pid,lstart,cmd -C apache2 # Startzeit prüfen, unter RHEL: -C httpd
- Übergangsmassnahmen setzen, wenn das Update noch nicht geht. php.net nennt unter anderem feste Grenzen, die Anwendungen nicht überschreiben können:
# Serverkonfiguration oder VirtualHost, nicht .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
Mit memory_limit=-1 gehört eine Speichergrenze über cgroup dazu, nicht über RLIMIT_AS oder RLIMIT_DATA. Diese Massnahmen sind kein vollständiger Schutz; die Details stehen unter Sofortmassnahmen, wenn Sie noch nicht patchen können. Geht beides nicht sofort, empfiehlt das BSI, den Webserver vorübergehend vom Netz zu nehmen.
Lief Ihr Apache mit mod_php zwischen dem 17. Oktober und dem Patch ungeschützt im Internet, sichern Sie die Logs ab dem 20. Oktober und lassen Sie den Server auf Spuren prüfen. Der Patch allein beweist nicht, dass nichts passiert ist.
Mittelfristig: weg von mod_php
Nach dem Patch lohnt der Blick auf die Architektur. Der Umstieg auf PHP-FPM mit Apache mpm_event und proxy_fcgi oder mit Nginx trennt PHP vom Webserver, erlaubt eigene Pools und Benutzer je Website und macht Neustarts und Versionswechsel einfacher. Er schliesst PHP2Shell nicht, verringert aber die Angriffsfläche künftiger Lücken.
Die Umstellung braucht Planung. Einstellungen, die bisher per php_value in .htaccess gesetzt wurden, wirken unter PHP-FPM nicht mehr und müssen in den Pool wandern. Benutzer und Rechte ändern sich, Upload- und Cache-Verzeichnisse brauchen eventuell neue Berechtigungen. In einer Testumgebung ist das gut beherrschbar, im laufenden Betrieb unter Zeitdruck nicht. Hinweise zur Umstellung finden Sie unter Apache mit mod_php absichern.
Wie hilft PHP SOS konkret?
- Erkennen: Wir prüfen, welche Server mod_php nutzen und aus welcher Paketquelle das Modul stammt.
- Patchen und neu starten: Über den PHP-Patch-Service spielen wir das Update ein und kontrollieren, dass kein alter Apache-Prozess mehr läuft.
- Übergang absichern: Wo das Update blockiert ist, setzen wir die Massnahmen von php.net in der Serverkonfiguration.
- Umstellen: Im Rahmen der Server-Härtung planen und testen wir den Wechsel auf PHP-FPM mit getrennten Pools.
Häufige Fragen
Woran erkenne ich, ob mein Apache mod_php nutzt?
Mit apachectl -M oder httpd -M sehen Sie die geladenen Module. Steht dort ein Modul wie php_module oder php8_module, läuft PHP direkt im Apache. Unter Debian und Ubuntu zeigt auch a2query -m an, ob ein php-Modul aktiv ist.
Schützt mich ein Sicherheits-Plugin in WordPress bei mod_php?
Bei dieser Lücke nicht. Laut PHP-Team wurde bei mod_php ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Ein Plugin ist Anwendungscode und kommt damit zu spät. Schutz bietet nur das PHP-Update mit Neustart von Apache.
Sollte ich jetzt von mod_php auf PHP-FPM umsteigen?
Zuerst patchen, dann umstellen. Der Wechsel auf PHP-FPM ist für die meisten Setups mittelfristig sinnvoll, weil PHP dann getrennt vom Webserver läuft. Er schliesst PHP2Shell aber nicht, denn PHP-FPM ist ebenfalls betroffen.