Aktuelle Lage: PHP2Shell. Zwei kritische PHP-Lücken (CVSS 9.2) erlauben Schadcode ohne Anmeldung. Patches seit 21.10.2026.Was jetzt zu tun ist →

mod_php erklärt: PHP im Apache-Prozess

Bei mod_php steckt PHP in jedem Apache-Prozess. Das ist einfach, aber unflexibel und nach PHP2Shell die riskanteste Betriebsart. So funktioniert sie und so erkennen Sie sie.

Stand 4 Min. LesezeitPHP-Wissen

Kurz gesagt: mod_php ist PHP als Modul im Apache-Webserver. Jeder Apache-Prozess enthält dann einen vollständigen PHP-Interpreter und führt PHP-Code selbst aus; die SAPI heisst apache2handler. Das ist einfach einzurichten, bindet PHP aber an Apache, verlangt meist das prefork-MPM und erlaubt kaum Trennung zwischen Websites. Das PHP-Handbuch rät für neue Installationen davon ab, und bei PHP2Shell stuft das PHP-Team das Risiko bei mod_php am höchsten ein.

Was ist mod_php?

Bei mod_php lädt Apache PHP als eigenes Modul in seine Prozesse. Es gibt keinen getrennten PHP-Dienst: Wenn Apache eine .php-Datei ausliefern soll, führt derselbe Prozess, der die Anfrage angenommen hat, auch den PHP-Code aus. Über viele Jahre war das der Standardweg, PHP zu betreiben, und er ist auf älteren Servern und in manchen Docker-Images bis heute verbreitet.

Laut PHP-Handbuch liest PHP als Servermodul seine Konfiguration nur einmal, beim Start des Webservers. Änderungen an der php.ini und Updates des Moduls wirken deshalb erst nach einem Neustart von Apache.

Wichtig für das Verständnis: Apache-Prozesse leben lange. Ein Prozess nimmt nacheinander viele Verbindungen an, bevor er ersetzt wird; wie viele, regelt die Apache-Direktive MaxConnectionsPerChild. Der eingebettete PHP-Interpreter bleibt in dieser Zeit derselbe. Wer die Bibliothek libphp auf der Festplatte austauscht, ändert an den laufenden Prozessen nichts.

Für Geschäftsführung und Projektverantwortliche lässt sich das so zusammenfassen: Bei mod_php sind Webserver und PHP eine Einheit. Wer das eine anfasst, betrifft das andere. Ein PHP-Update bedeutet einen Neustart des Webservers, ein Fehler in PHP läuft mit den Rechten des Webservers, und eine Trennung zwischen mehreren Websites auf demselben Server ist kaum möglich.

Wie wird mod_php eingebunden?

Das PHP-Handbuch zeigt die Einbindung in zwei Schritten: Modul laden und festlegen, welche Dateien PHP verarbeiten soll.

LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>

Das Handbuch empfiehlt FilesMatch mit SetHandler statt nur AddType, damit hochgeladene Dateien wie bild.php.jpg nicht als PHP ausgeführt werden. Unter Debian und Ubuntu übernehmen Pakete wie libapache2-mod-php8.3 und die Befehle a2enmod und a2dismod diese Arbeit.

Ob mod_php aktiv ist, lässt sich lesend prüfen:

apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # RHEL-Familie
apachectl -V | grep -i mpm               # aktives MPM (prefork, worker, event)

Prefork, Thread Safety und Ressourcen

Apache verteilt Anfragen über ein Multi-Processing-Modul (MPM). Laut PHP-Handbuch benötigt mod_php das prefork-MPM, sofern PHP nicht mit Zend Thread Safety (--enable-zts) gebaut wurde. Die meisten Distributionspakete sind ohne Thread Safety gebaut.

Prefork bedeutet: ein Prozess pro gleichzeitiger Verbindung, und jeder Prozess trägt einen kompletten PHP-Interpreter. Auch Anfragen nach Bildern oder CSS-Dateien belegen damit einen Prozess mit PHP im Gepäck. Das kostet Speicher und begrenzt die Last, die ein Server tragen kann.

Merkmal mod_php PHP-FPM
Wo läuft PHP? in jedem Apache-Prozess in eigenem Dienst
Apache-MPM meist prefork event möglich
Benutzer je Website nein, alles als Apache-Benutzer ja, je Pool
PHP neu starten nur mit Apache unabhängig von Apache
Einstellungen je Verzeichnis php_value in .htaccess Pool oder .user.ini

Das Handbuch empfiehlt deshalb für alle modernen Installationen PHP-FPM mit mod_proxy_fcgi: bessere Ressourcenverwaltung, Prozesstrennung, Neustart von PHP ohne Apache-Neustart und Kompatibilität mit dem event-MPM, das seit Apache 2.4 Standard ist. Die Grundlagen stehen unter PHP-FPM erklärt.

Einstellungen mit .htaccess, php_value und php_admin_value

Mit mod_php lassen sich PHP-Einstellungen direkt in der Apache-Konfiguration setzen. Das Handbuch unterscheidet dabei Änderungsmodi: Einträge mit INI_PERDIR dürfen in php.ini, .htaccess oder httpd.conf stehen, Einträge mit INI_SYSTEM nur in php.ini oder httpd.conf.

# In der VirtualHost-Konfiguration: für die Anwendung gesperrt
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# In .htaccess möglich, aber von der Anwendung überschreibbar
php_value max_execution_time 60

php_admin_value und php_admin_flag sind nur in der Serverkonfiguration erlaubt, nicht in .htaccess. Genau diese Unterscheidung ist bei den Übergangsmassnahmen zu PHP2Shell wichtig, weil Werte wie session.upload_progress.enabled nicht von der Anwendung zurückgesetzt werden dürfen.

mod_php und PHP2Shell: warum das Risiko am höchsten ist

Das PHP-Team stuft das Risiko durch PHP2Shell bei mod_php am höchsten ein: Dort wurde ein Exploit gezeigt, bevor überhaupt Anwendungscode läuft. Sicherheits-Plugins oder Prüfungen im CMS kommen damit zu spät. Hinzu kommt, dass PHP bei mod_php mit den Rechten und im Speicher des Webservers läuft. Die ausführliche Einordnung steht unter Warum mod_php das höchste Risiko trägt.

Für Betreiber gilt deshalb:

  1. PHP-Modul auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. einen bestätigten Backport aktualisieren.
  2. Apache vollständig neu starten, nicht nur neu laden, und die Startzeit der Prozesse prüfen.
  3. Übergangswerte per php_admin_value in der Serverkonfiguration setzen, wenn das Update noch nicht möglich ist.
  4. Danach den Umstieg auf PHP-FPM planen, wie unter Apache mit mod_php absichern beschrieben.

Wie hilft PHP SOS konkret?

  • Erkennen: Wir prüfen, auf welchen Servern mod_php läuft, mit welchem MPM und aus welcher Paketquelle.
  • Patchen: Wir aktualisieren das PHP-Modul, starten Apache vollständig neu und belegen den Stand.
  • Übergang sichern: Wo das Update blockiert ist, setzen wir die Massnahmen von php.net gesperrt in der Serverkonfiguration.
  • Umstellen: Im Rahmen der Server-Härtung migrieren wir getestet auf PHP-FPM mit eigenen Pools.

Häufige Fragen

Warum heisst es mod_php, wenn das Modul php_module heisst?

mod_php ist der umgangssprachliche Name für PHP als Apache-Modul. In der Konfiguration wird es mit LoadModule geladen; das PHP-Handbuch nennt als Beispiel LoadModule php_module modules/libphp.so. Ältere Versionen nutzten Namen wie php7_module oder php5_module.

Warum braucht mod_php das prefork-MPM?

Laut PHP-Handbuch benötigt mod_php das prefork-MPM, sofern PHP nicht mit Zend Thread Safety gebaut wurde. Die meisten Distributionspakete sind ohne Thread Safety gebaut. Prefork startet für jede gleichzeitige Verbindung einen eigenen Prozess, was mehr Speicher braucht.

Funktionieren php_value-Zeilen in .htaccess auch mit PHP-FPM?

Nein. php_value und php_flag in .htaccess sind Apache-Direktiven des PHP-Moduls und wirken nur mit mod_php. Unter PHP-FPM gehören solche Einstellungen in den Pool oder, für erlaubte Werte, in eine .user.ini.

Muss ich mod_php sofort abschaffen?

Zuerst kommt das Update von PHP mit vollständigem Neustart von Apache. Der Wechsel auf PHP-FPM ist danach sinnvoll, sollte aber geplant und getestet werden. Er schliesst PHP2Shell nicht, weil PHP-FPM ebenfalls betroffen ist.

Quellen

Sofort-Kontakt

Jede Stunde zählt. Schreiben Sie uns jetzt.

Schildern Sie kurz System, PHP-Version und Beobachtung. Wir melden uns, klären die Lage und arbeiten remote, bis der Vorfall abgeschlossen und dokumentiert ist.

Sofort-Hilfe