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; doneVergleiche 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.
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_sizeverringern 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.