# Apache mit mod_php absichern > Apache mod_php nach PHP2Shell: Betriebsart erkennen, PHP-Modul patchen, Apache vollständig neu starten und den Umstieg auf PHP-FPM sauber vorbereiten. Quelle: https://phpsos.de/server/apache-mod-php/ Stand: 25.10.2026 Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6 **Kurz gesagt:** Bei Apache mit mod_php läuft PHP direkt im Webserver. Das PHP-Team stuft das Risiko durch PHP2Shell genau in dieser Betriebsart am höchsten ein, weil ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft. Patchen Sie sofort, starten Sie Apache vollständig neu und planen Sie danach den Umstieg auf PHP-FPM. ## Was mod_php ist und warum es jetzt zählt Bei mod_php lädt Apache PHP als Modul in jeden eigenen Arbeitsprozess. Jede Anfrage an eine PHP-Datei wird direkt in diesem Prozess ausgeführt. Das war lange der Standard und ist einfach einzurichten. Es bedeutet aber auch: Alle Websites auf dem Server laufen mit demselben Benutzer, und PHP teilt sich den Prozess mit dem Webserver. PHP2Shell umfasst die Lücken CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2. Bei der zweiten kann interner Zustand einer Anfrage nach dem Freigeben des Speichers bestehen bleiben und von einer späteren Anfrage im selben Prozess genutzt werden. Für mod_php hat das PHP-Team das höchste Risiko festgestellt. Hintergrund und Einordnung stehen unter [Warum mod_php das höchste Risiko trägt](https://phpsos.de/php2shell/mod-php-risiko/). ## Apache mod_php erkennen und Version prüfen Prüfen Sie zuerst, ob Ihr Apache überhaupt mod_php nutzt. Die folgenden Befehle lesen nur. Befehls- und Paketnamen unterscheiden sich je Distribution und sind Beispiele. ```bash # Debian/Ubuntu: geladene Module apache2ctl -M 2>/dev/null | grep -i php # RHEL-Familie httpd -M 2>/dev/null | grep -i php # Welches MPM ist aktiv? mod_php setzt prefork voraus apache2ctl -V 2>/dev/null | grep -i mpm # Paketstand des Moduls (Beispiele) dpkg -l | grep libapache2-mod-php rpm -qa | grep -E '^php(-[0-9.]+)?$|^php-common' ``` Erscheint ein Modul wie `php_module`, läuft mod_php. Die angezeigte PHP-Version allein ist kein Beleg für den Patch, weil Distributionen Fixes oft als Backport einspielen. Behobene Versionen des PHP-Projekts sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Bei Distributionspaketen zählt das Änderungsprotokoll mit den CVE-Nummern. ## Patchen und Apache vollständig neu starten Spielen Sie das Update über die Paketverwaltung ein. Weil PHP im Apache-Prozess steckt, muss danach der ganze Dienst neu starten. Ein Neuladen der Konfiguration ist hier nicht der sichere Weg. ```bash # Debian/Ubuntu systemctl restart apache2 # RHEL-Familie systemctl restart httpd # Kontrolle: Startzeit aller Apache-Prozesse ps -eo pid,lstart,cmd | grep -E 'apache2|httpd' | grep -v grep ``` Alle Apache-Prozesse müssen eine Startzeit nach dem Update zeigen. Läuft auf demselben Server zusätzlich PHP-FPM oder php-cgi, starten Sie auch diese Dienste neu. > **Sofort handeln:** > Ist für Ihre PHP-Version noch kein Patch verfügbar, empfiehlt das BSI, den Webserver vorübergehend vom Netz zu nehmen. Bei mod_php wiegt das besonders schwer, weil der Angriff vor dem Anwendungscode greifen kann. ## Übergangsmaßnahmen in der Apache-Konfiguration php.net nennt Übergangsmaßnahmen, die das Risiko senken, aber keinen vollständigen Schutz bieten. Bei mod_php setzen Sie die Werte mit `php_admin_value` beziehungsweise `php_admin_flag` in der Apache-Konfiguration, damit `.htaccess` und Anwendungen sie nicht überschreiben können. ```apache # Beispiel: in der VirtualHost- oder serverweiten Konfiguration php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` Mit Upload-Funktion nennt php.net `post_max_size = 32M`, `upload_max_filesize` darunter. Auf PHP 8.5 kommt `fatal_error_backtraces=0` hinzu. Den Hinweis zu `memory_limit=-1` setzen Sie nur zusammen mit einer Speichergrenze für den Dienst über cgroups um, etwa per `MemoryMax` in einer systemd-Ergänzung, nicht über `RLIMIT_AS` oder `RLIMIT_DATA`. Danach Apache vollständig neu starten. Alle Maßnahmen im Überblick: [Sofortmaßnahmen ohne Patch](https://phpsos.de/php2shell/sofortmassnahmen-ohne-patch/). ## Der Weg weg von mod_php Nach dem akuten Patch lohnt der Umstieg auf PHP-FPM. Dabei läuft PHP in eigenen Prozessen, getrennt vom Webserver. Jede Website kann einen eigenen Pool mit eigenem Benutzer erhalten, Grenzen lassen sich je Pool setzen, und Neustarts betreffen nur PHP. Apache bindet PHP-FPM über `mod_proxy_fcgi` an und kann dann statt prefork ein moderneres MPM wie event nutzen. Planen Sie den Wechsel in einer Testumgebung: Pools je Website anlegen, Dateirechte an die neuen Benutzer anpassen, `.htaccess`-Einträge mit `php_value` in Pool-Einstellungen überführen, Lasttests fahren. Wie ein sauberer Aufbau aussieht, zeigt [Nginx mit PHP-FPM absichern](https://phpsos.de/server/nginx-php-fpm/); die Grundsätze gelten für Apache mit PHP-FPM ebenso. Unabhängig von der Betriebsart gilt: Ein Patch entfernt keine bereits eingeschleuste Schadsoftware. Bewahren Sie die Logs ab dem 20.10.2026 auf und prüfen Sie den Server auf Spuren. Bei der Spurensuche auf mod_php-Servern lohnt ein Blick auf den gemeinsamen Benutzer. Weil alle Websites unter dem Apache-Benutzer laufen, etwa `www-data` oder `apache`, kann ein Angreifer, der eine Website übernommen hat, in der Regel auch die Dateien der anderen lesen und verändern. Prüfen Sie deshalb nicht nur die Website, die Ihnen auffällig erscheint, sondern alle Document-Roots auf dem Server. Achten Sie besonders auf PHP-Dateien mit jungem Änderungsdatum in Upload- und Cache-Verzeichnissen, auf Programmcode, der dem Apache-Benutzer gehört, und auf unbekannte Einträge in der Crontab dieses Benutzers. Finden Sie etwas, sichern Sie zuerst den Zustand und löschen Sie nicht vorschnell, damit die Ursache später nachvollziehbar bleibt. ## Wie hilft PHP SOS konkret? - Wir prüfen Betriebsart, MPM und Paketstand und bewerten, ob Ihr Server tatsächlich gepatcht ist. - Über den [PHP-Patch-Service](https://phpsos.de/leistungen/php-patch-service/) spielen wir das Update ein, starten Apache vollständig neu und dokumentieren den Nachweis. - Bis zum Patch setzen wir die Übergangsmaßnahmen nicht überschreibbar und begrenzen den Speicher auf Dienstebene. - Im Rahmen der [Server-Härtung](https://phpsos.de/leistungen/server-haertung/) planen und testen wir den Umstieg auf PHP-FPM mit getrennten Pools. ## Häufige Fragen **Wie erkenne ich, ob mein Server mod_php nutzt?** Wenn Apache ein PHP-Modul geladen hat, erscheint es in der Modulliste als php_module oder mit Versionsnummer im Namen. Zusätzlich zeigt eine phpinfo-Ausgabe unter Server API den Eintrag Apache 2.0 Handler. Löschen Sie eine solche Testdatei sofort wieder. **Warum ist mod_php bei PHP2Shell besonders kritisch?** Laut PHP-Team ist das Risiko dort am höchsten; es wurde ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Damit schützt auch eine gut gepflegte Anwendung nicht. Ein schnelles Update hat deshalb höchste Priorität. **Reicht ein Reload von Apache nach dem Update?** Sicher ist ein vollständiger Neustart des Dienstes, weil PHP als Modul in den Apache-Prozessen steckt. Prüfen Sie danach die Startzeit aller Apache-Prozesse. Ältere Prozesse als das Update dürfen nicht übrig bleiben. **Ist der Wechsel auf PHP-FPM aufwendig?** Meist ist er gut planbar: PHP-FPM installieren, Pools anlegen, Apache auf proxy_fcgi umstellen und von prefork auf ein anderes MPM wechseln. Testen Sie das vorher in einer Kopie der Umgebung. ## Quellen - [php.net: Sicherheitsmeldungen](https://www.php.net/) - [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php) - [BSI](https://www.bsi.bund.de/) - [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)