Mehrere PHP-Versionen auf einem Server: Jede einzeln patchen

Kurz gesagt: Laufen mehrere PHP-Versionen auf einem Server, muss nach PHP2Shell jede einzeln geprüft, aktualisiert und neu gestartet werden. Typische Quellen sind das Betriebssystem, Hosting-Panels wie Plesk oder cPanel, Drittquellen wie sury.org oder Remi, CloudLinux, LiteSpeed und selbst kompilierte Versionen. Erst eine vollständige Liste aus Paketen, Dateien und laufenden Prozessen zeigt, ob wirklich keine Version übersehen wurde.

Die vergessene Version

Ein Server, der seit einigen Jahren läuft, sammelt PHP-Versionen wie ein Dachboden alte Möbel. Das Panel brachte drei Zweige mit, für einen Kunden kam eine ältere Version aus einer Drittquelle dazu, das Betriebssystem hat seine eigene. Jede davon wurde einmal aus gutem Grund installiert. Nur weiß heute niemand mehr, welche noch gebraucht wird.

Nach PHP2Shell ist genau das ein Problem. Die Korrekturen erschienen am 21. Oktober 2026 für PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Jede Installation auf dem Server erhält sie aber auf ihrem eigenen Weg, vom eigenen Paketbetreuer und zu eigener Zeit. Für PHP 8.1 und älter gibt es nur minimale Quell-Backports. Wer nur die Hauptversion aktualisiert, lässt die anderen offen.

Woher die vielen Versionen kommen

Die folgende Übersicht nennt typische Quellen und Beispielpfade. Die genauen Pfade unterscheiden sich je Version und Distribution.

Besonders tückisch sind sury.org-Pakete, weil sie dieselben Pfade nutzen wie die Distribution. Ob ein php8.3 aus Debian oder aus sury.org stammt, zeigt erst die Paketquelle. Die Besonderheiten beschreiben die Beiträge Das sury.org-Repository und Das Remi-Repository. Wie Plesk seine Versionen verwaltet, beschreibt die Seite Plesk-Server: PHP-Versionen prüfen und patchen.

Alle PHP-Installationen finden

Eine verlässliche Liste entsteht aus drei Blickwinkeln. Die Befehle sind rein lesend und können je nach Server einige Zeit laufen.

# 1. Pakete: was die Paketverwaltung kennt
dpkg-query -W -f='${Package}\t${Version}\n' '*php*' 2>/dev/null | grep -E "fpm|cli|cgi|mod-php|lsphp"
rpm -qa 2>/dev/null | grep -iE "php.*(fpm|cli|cgi|litespeed)|^php-[0-9]|^ea-php|^alt-php" | sort

# 2. Dateien: ausführbare PHP-Binaries, auch außerhalb der Paketverwaltung
find / -xdev -type f \( -name 'php' -o -name 'php[0-9]*' -o -name 'php-fpm*' -o -name 'php-cgi*' -o -name 'lsphp*' \) -perm -u+x 2>/dev/null

# 3. Prozesse: was gerade wirklich läuft, mit Startzeit
ps -eo pid,user,lstart,cmd | grep -E "[p]hp-fpm|[p]hp-cgi|[l]sphp|[a]pache2|[h]ttpd|[f]rankenphp"

Gleichen Sie die drei Listen ab. Eine Datei ohne Paket deutet auf eine selbst kompilierte oder manuell kopierte Version hin. Ein Prozess ohne passende Datei kann auf eine gelöschte, aber noch laufende Installation hinweisen. Prüfen Sie bei Apache zusätzlich, ob ein PHP-Modul geladen ist, etwa mit apache2ctl -M oder httpd -M. Container und Kubernetes-Pods tauchen in diesen Listen nur teilweise auf und brauchen eine eigene Prüfung der Images.

Jede Version einzeln patchen

Hat jede Installation eine Zeile in Ihrer Liste, folgt für jede derselbe Ablauf:

1. Zuständigkeit klären: Kommt der Patch von der Distribution, vom Panel, aus einer Drittquelle oder von Ihnen selbst?
2. Stand bewerten: offizielle korrigierte Version, bestätigter Backport, ungeklärt oder offen.
3. Aktualisieren: über den Weg der jeweiligen Quelle, nicht über einen anderen.
4. Neu starten: den Dienst dieser Version, nicht nur den Hauptdienst. Bei mod_php den Webserver. Einzelheiten stehen unter PHP-FPM und alle Worker neu starten.
5. Kontrollieren: Startzeit der Prozesse mit dem Update-Zeitpunkt vergleichen.
6. Dokumentieren: Version, Paketstand, Beleg, Neustartzeit.

Für Versionen, für die es keinen Patch gibt, gelten bis zur Migration die Übergangsmaßnahmen von php.net. Setzen Sie diese für jede Version gesondert, denn jede Installation hat ihre eigene php.ini und ihre eigenen Pools.

Welche Version nutzt die Kommandozeile, welche der Container?

Zwei Bereiche fallen bei der Suche besonders oft durch das Raster. Der erste ist die Kommandozeile. Unter Debian und Ubuntu entscheidet das Alternativen-System, welches Binary hinter dem Befehl php steckt. update-alternatives --display php zeigt, welche Versionen registriert sind und welche gerade gilt. Cronjobs, die einen festen Pfad wie /usr/bin/php7.4 aufrufen, umgehen diese Einstellung allerdings. Deshalb lohnt der Blick in die Crontabs aller Benutzer und in die Konfiguration von Panels, die eigene Cronjobs anlegen.

Der zweite Bereich sind Container. Ein Docker-Container auf dem Server bringt seine eigene PHP-Version mit, die in keiner Paketliste des Hosts auftaucht. docker ps zeigt laufende Container; ob PHP darin steckt und in welcher Version, verrät ein Blick in das Image oder ein php -v im Container. Der Patch erfolgt dort nicht auf dem Host, sondern durch Neubau des Images und Austausch des Containers.

Weniger ist sicherer

Die beste Prüfung ist die, die man nicht machen muss. Jede installierte PHP-Version verdoppelt den Aufwand bei der nächsten Lücke. Nach PHP2Shell lohnt sich deshalb eine klare Regel: Jede Version auf dem Server braucht einen Zweck und einen Verantwortlichen. Was keinen hat, wird erst deaktiviert und nach einer Beobachtungszeit entfernt. Mehr dazu im Beitrag Alte PHP-Versionen im Hosting-Panel abschalten.

Wie hilft PHP SOS konkret?

• Wir erstellen für Ihre Server eine vollständige Liste aller PHP-Installationen aus Paketen, Dateien, Prozessen und Containern.
• Wir klären je Version Herkunft, Zuständigkeit und Patchstand.
• Im Rahmen des PHP-Patch-Service aktualisieren wir jede Version, starten jeden Dienst neu und belegen den Stand.
• Gemeinsam mit Ihnen legen wir fest, welche Versionen bleiben, und entfernen die übrigen kontrolliert.

Häufige Fragen

Quellen

• php.net: Sicherheitsmeldungen
• php.net: Unterstützte Versionen
• Red Hat Security Bulletin RHSB-2026-013