# Warum mod_php das höchste Risiko trägt

> Warum das PHP-Team das Risiko von PHP2Shell bei Apache mit mod_php am höchsten einstuft, wie Sie mod_php erkennen und was Sie jetzt patchen und umstellen.

Quelle: https://phpsos.de/php2shell/mod-php-risiko/  
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:** 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 weiß, 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 Schutzmaßnahmen 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 heißt das: Betreiben Sie mehrere Server, kommen die mit mod_php zuerst an die Reihe, und bei ihnen ist eine anschließende 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`.

```bash
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](https://phpsos.de/server/nginx-php-fpm/) sinngemäß.

## Was mod_php-Betreiber jetzt tun sollten

1. **PHP-Modul aktualisieren** auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder einen bestätigten Backport Ihrer Distribution.
2. **Apache vollständig neu starten,** nicht nur neu laden. Bei mod_php steckt der alte PHP-Code in jedem Apache-Prozess.

```bash
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
```

3. **Übergangsmaßnahmen setzen, wenn das Update noch nicht geht.** php.net nennt unter anderem feste Grenzen, die Anwendungen nicht überschreiben können:

```apache
# 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 Maßnahmen sind kein vollständiger Schutz; die Details stehen unter [Sofortmaßnahmen, wenn Sie noch nicht patchen können](https://phpsos.de/php2shell/sofortmassnahmen-ohne-patch/). Geht beides nicht sofort, empfiehlt das BSI, den Webserver vorübergehend vom Netz zu nehmen.

> **Sofort handeln:**
> 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 schließt 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](https://phpsos.de/server/apache-mod-php/).

## 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](https://phpsos.de/leistungen/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 Maßnahmen von php.net in der Serverkonfiguration.
- **Umstellen:** Im Rahmen der [Server-Härtung](https://phpsos.de/leistungen/server-haertung/) 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 schließt PHP2Shell aber nicht, denn PHP-FPM ist ebenfalls betroffen.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik](https://www.bsi.bund.de/)