PHP-Notfall-Update (PHP2Shell): So prüfst und patchst du deine Server

Das PHP-Team hat am 21. Oktober 2026 Notfall-Updates für zwei kritische Schwachstellen veröffentlicht (CVE-2026-109618 und CVE-2026-109619, zusammen „PHP2Shell“, je 9,2 nach CVSS 4.0). Sie liegen in der Laufzeit selbst, nicht in einer Anwendung: Auch eine „Hello World“-Seite auf einer verwundbaren PHP-Version ist angreifbar, ganz ohne Konto. Behoben ist es in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Entdeckt haben es Forscher von Wiz, Calif und OpenAI.

Warum ein Anwendungs-Update nicht reicht

WordPress, Laravel oder Nextcloud zu aktualisieren, ändert nichts an der PHP-Version darunter. Die kommt aus dem Server-Paket, vom Hosting oder aus dem Container-Image. Betroffen sind laut PHP-Advisory alle Betriebsarten (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). Am gefährlichsten ist mod_php: Dort kann eine einzelne Anfrage den Angriff auslösen, bevor Anwendungscode läuft. Zusätzlich lässt sich Speicher des PHP-Prozesses auslesen, in dem Passwörter, Tokens und Schlüssel anderer Anfragen liegen können.

Schritt 1: Finde alle PHP-Installationen

„Ein PHP“ gibt es auf einem Server selten. Typische Orte:

• Systempaket der Distribution (php -v, php-fpm).
• Panel-eigene Versionen, etwa Plesk unter /opt/plesk/php/*.
• Container: Nextcloud, WordPress & Co. bringen ihr eigenes PHP im Image mit (docker exec NAME php -v).
• Zusätzliche Handler pro Website, die auf einer anderen Version stehen als der Rest.

php -v
ls /opt/plesk/php/ 2>/dev/null
for c in $(docker ps --format '{{.Names}}'); do echo -n "$c: "; docker exec $c php -v 2>/dev/null | head -1; echo; done

Vergleiche jede Version mit der Tabelle: unter 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 ist verwundbar. PHP 8.1 und älter bekommt keine Updates mehr, für 7.4, 8.0 und 8.1 gibt es nur Quell-Backports; 8.2 endet am 31. Dezember 2026.

Schritt 2: Patchen und neu starten

Auf Debian/Ubuntu normal per apt update && apt upgrade. Wichtig: Distributionen bringen den Fix oft unter einer „alten“ Versionsnummer. Prüfe deshalb das Changelog des Pakets auf die CVE-Nummer statt nur auf die Versionszeichenfolge. Danach PHP-FPM bzw. Apache neu starten, auch lang laufende PHP-Worker. Ohne Neustart läuft der alte Code weiter.

Praxisbeispiel: Mein Server heute Abend

Auf meinem Plesk-Server hatte ich drei Quellen: das Ubuntu-Systempaket (8.3.6), Plesk-PHP 8.5.11 und zwei Docker-Images mit eigenem PHP. Ergebnis:

• Plesk-PHP 8.5 ließ sich über den Plesk-Installer auf 8.5.12 aktualisieren.
• Für das Ubuntu-Paket gab es noch keinen Fix. Statt zu warten, habe ich Plesk-PHP 8.3 (jetzt 8.3.36) installiert und die Websites auf diesen Handler umgestellt. Gleiche Minor-Version, daher kaum Kompatibilitätsrisiko. Danach jede Seite einzeln geprüft.
• Die Container (Nextcloud AIO) haben noch eigenes, älteres PHP. Dort hilft nur das neue Image, sobald es erscheint.

Synology, Plesk, Webhosting, Docker: Was ist zu tun?

• Webhosting (Shared Hosting, z. B. bei STRATO oder IONOS): PHP wird vom Anbieter betrieben und aktualisiert. In der Verwaltung prüfen, welche PHP-Version für die Website eingestellt ist, und auf eine unterstützte Version wechseln. Die eigene Anwendung (WordPress, Nextcloud, Shop) trotzdem aktuell halten. Das ist meine fachliche Einschätzung, keine Aussage eines Anbieters.
• Plesk: Jede PHP-Version ist ein eigenes Paket. Updates über die Plesk-Aktualisierung oder die Paketverwaltung einspielen, dann prüfen: /opt/plesk/php/8.3/bin/php -v (für jede installierte Version) und plesk bin php_handler --list.
• Synology: PHP kommt über Web Station und das Paket-Zentrum. Solange Synology kein Update liefert, hilft nur das Entschärfen per php.ini: Anleitung für NAS, Plesk und eigene Server.
• Docker und Container: Das Update steckt im Image. docker compose pull && docker compose up -d, danach docker exec <container> php -v.

Ein paar Ratschläge

• Inventar zuerst: Schreib dir auf, wo PHP läuft (System, Panel, Container). Beim nächsten Notfall sparst du die Suche.
• mod_php meiden: Wenn möglich auf PHP-FPM wechseln. Das verkleinert die Angriffsfläche und erlaubt getrennte Pools.
• Nach jeder Umstellung testen: Startseite, Login, Formulare, Cronjobs. Ein 200 auf der Startseite genügt nicht.
• Notlösungen sind keine Lösung: Limits wie ein kleines post_max_size verringern nur einzelne Angriffswege. Das Update bleibt Pflicht.
• Ende der Unterstützung einplanen: Wer auf 8.1 oder älter sitzt, braucht einen Migrationsplan, nicht nur diesen Patch. 8.2 endet in zwei Monaten.
• Passwörter im Blick behalten: Weil Speicher auslesbar war, sind bei verdächtigen Spuren Tokens und Schlüssel zu rotieren.

Quellen: The Hacker News und das PHP-Sicherheits-Advisory.