Plesk-Server: PHP-Versionen prüfen und patchen

Kurz gesagt: Ein Plesk PHP-Update ist erst abgeschlossen, wenn jede installierte PHP-Version auf einem behobenen Stand ist, alle PHP-FPM-Dienste neu gestartet wurden und Sie das mit Paketstand und Prozess-Startzeit belegen können. Die im Panel angezeigte Versionsnummer allein reicht dafür nicht, weil Backports sie oft unverändert lassen.

Worum es bei PHP2Shell auf Plesk-Servern geht

PHP2Shell bezeichnet zwei kritische Lücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619, je CVSS v4.0 9.2). Sie erlauben Angreifern, ohne Anmeldung Code auf dem Server auszuführen. Betroffen sind unter anderem PHP-FPM und Apache mit mod_php, also genau die Betriebsarten, die Plesk für Websites einrichtet.

Am 21.10.2026 hat das PHP-Projekt die behobenen Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr. Plesk-Server haben eine Besonderheit: Hier laufen häufig mehrere PHP-Versionen nebeneinander, teils von Plesk selbst, teils vom Betriebssystem. Jede davon braucht eine eigene Prüfung.

Plesk PHP-Update: zuerst den Bestand erfassen

Bevor Sie etwas aktualisieren, verschaffen Sie sich eine Liste aller PHP-Handler und der Domains, die sie nutzen. Das gelingt über das Panel (Werkzeuge & Einstellungen, PHP-Einstellungen) oder per Kommandozeile. Die folgenden Befehle verändern nichts, sie lesen nur.

# Alle registrierten PHP-Handler mit Version und Pfad
plesk bin php_handler --list

# Version jeder von Plesk installierten PHP-Version (Pfad als Beispiel)
for p in /opt/plesk/php/*/bin/php; do echo "$p"; "$p" -v | head -1; done

Notieren Sie für jeden Handler: Version, Betriebsart (FPM, FastCGI, Apache-Modul) und die Anzahl der Domains. Handler ohne Domain sind keine Entwarnung. Sie können später zugewiesen werden oder auf Test-Subdomains laufen.

Paketstand statt Anzeige prüfen

Plesk zeigt die Versionsnummer an, die PHP selbst meldet. Liefern Plesk oder die Distribution den Fix als Backport, kann dort weiterhin etwa 8.2.34 stehen, obwohl die Korrektur enthalten ist. Umgekehrt kann eine aktuell wirkende Nummer täuschen, wenn ein Paket noch nicht nachgezogen wurde. Entscheidend sind der installierte Paketstand und die schriftliche Bestätigung des Anbieters.

# Debian/Ubuntu (Paketnamen als Beispiel)
dpkg -l | grep -E 'plesk-php|php[0-9.]+-(fpm|cli)'

# AlmaLinux/Rocky/RHEL (Paketnamen als Beispiel)
rpm -qa | grep -E 'plesk-php|^php' | sort

Vergleichen Sie die Paketversionen mit den Angaben in den Plesk-Änderungsprotokollen und den Hinweisen Ihrer Distribution. Ist dort nicht eindeutig dokumentiert, dass CVE-2026-109618 und CVE-2026-109619 behoben sind, fragen Sie beim Anbieter nach. Eine Vorlage dafür finden Sie unter Hoster nach dem Patch-Status fragen.

Update einspielen und alle Worker neu starten

Das eigentliche Update läuft über den Plesk-Installer oder die Paketverwaltung des Systems. Danach folgt der Schritt, der am häufigsten fehlt: der Neustart. Jede PHP-Version hat unter Plesk einen eigenen FPM-Dienst. Starten Sie alle neu, nicht nur den der Hauptdomain.

# Alle PHP-FPM-Dienste auflisten (Dienstnamen als Beispiel)
systemctl list-units --type=service | grep -i 'php.*fpm'

# Je Dienst neu starten, z. B.:
systemctl restart plesk-php84-fpm

# Startzeit der laufenden PHP-Prozesse prüfen
ps -eo pid,lstart,cmd | grep -E 'php-fpm|php-cgi' | grep -v grep

Läuft eine Domain mit Apache und mod_php, starten Sie Apache vollständig neu. Liegt die Startzeit eines PHP-Prozesses vor dem Update, ist er noch nicht erneuert. Mehr zu diesem Schritt steht unter PHP-FPM und alle Worker neu starten.

Übergangsschutz, wenn das Update noch fehlt

Ist für eine Version noch kein Patch verfügbar, empfiehlt php.net Übergangsmassnahmen. Sie sind kein vollständiger Schutz. Unter Plesk setzen Sie Werte, die Anwendungen nicht überschreiben dürfen, als php_admin_value in den zusätzlichen FPM-Direktiven der Domain oder serverweit in der php.ini der jeweiligen Version.

; Beispiel für zusätzliche PHP-FPM-Direktiven in Plesk
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M

Mit Uploads ist laut php.net post_max_size = 32M vorgesehen, upload_max_filesize darunter. Auf PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Die Speicherbegrenzung über memory_limit=-1 gehört nur zusammen mit einer Grenze auf Container- oder cgroup-Ebene eingesetzt. Danach folgt wieder ein Neustart aller Worker. Einzelheiten stehen unter Sofortmassnahmen ohne Patch. Das BSI empfiehlt, Webserver vorübergehend vom Netz zu nehmen, wenn das Update nicht sofort möglich ist.

Nach dem Patch: Logs sichern und Spuren prüfen

Ein Patch schliesst die Lücke für die Zukunft. Er entfernt keine Schadsoftware, die vorher eingeschleust wurde, und belegt nicht, dass nichts passiert ist. Bewahren Sie deshalb die Webserver-Logs ab dem 20.10.2026 auf. Plesk legt sie je Domain unter dem Verzeichnis logs ab; kürzen Sie die Aufbewahrung in dieser Lage nicht.

Achten Sie auf neue oder veränderte PHP-Dateien in Upload-Verzeichnissen, unbekannte geplante Aufgaben und neue Administrator-Konten. Veröffentlichte, bestätigte Indicators of Compromise gibt es bislang nicht; die Erkennung beruht auf Verhaltensanalyse. Wenn Sie Auffälligkeiten finden, arbeiten Sie nicht auf eigene Faust weiter, sondern sichern Sie zuerst den Zustand.

Wie hilft PHP SOS konkret?

• Wir erfassen alle PHP-Handler Ihres Plesk-Servers, ordnen Domains zu und prüfen den tatsächlichen Paketstand je Version.
• Im Rahmen unseres PHP-Patch-Service spielen wir Updates ein, starten alle Dienste neu und dokumentieren Prozess-Startzeiten als Nachweis.
• Wo ein Patch fehlt, setzen wir die Übergangsmassnahmen nach php.net serverweit und nicht überschreibbar.
• Wir sichern Logs und suchen nach Spuren einer Kompromittierung, bei Befund mit Incident Response.
• Danach härten wir den Server dauerhaft und entfernen nicht benötigte PHP-Versionen.

Häufige Fragen

Quellen

• php.net: Sicherheitsmeldungen
• PHP 8 ChangeLog
• php.net: Unterstützte Versionen
• BSI