Ein Update ist erst der Anfang
Bei einer kritischen Sicherheitslücke muss es schnell gehen. Schnell bedeutet allerdings nicht, irgendein Update anzustoßen und anschließend davon auszugehen, dass die Aufgabe erledigt ist.
Die PHP2Shell-Schwachstellen CVE-2026-109618 und CVE-2026-109619 werden durch korrigierte PHP-Versionen beziehungsweise entsprechend korrigierte Herstellerpakete geschlossen. Konfigurationsänderungen können einzelne Angriffswege erschweren, ersetzen aber nicht die vollständige Korrektur. [1][2]
Der entscheidende Unterschied lautet: Ein korrigiertes Paket muss nicht nur auf dem Server liegen. Die betreffende Anwendung muss auch tatsächlich mit der korrigierten Laufzeit arbeiten.
Welche offiziellen PHP-Versionen die Fehler beheben
Für die regulären Veröffentlichungen des PHP-Projekts gelten zum Recherchezeitpunkt folgende Mindeststände:
Die Tabelle bezieht sich auf die unveränderten Veröffentlichungen des PHP-Projekts. Bei Linux-Distributionen oder betreuten Herstellerpaketen können die Korrekturen unter einer anderen vollständigen Paketversionsnummer ausgeliefert werden. [1][3]
Für eine Anwendung mit PHP 8.3 muss deshalb nicht zwangsläufig sofort ein größerer Wechsel auf PHP 8.5 erfolgen. Zunächst ist die Sicherheitskorrektur innerhalb der verwendeten, unterstützten Reihe zu prüfen.
Eine Notfallkorrektur würde ich nicht ohne konkreten Grund mit einer umfassenden Modernisierung der Anwendung verbinden.
| PHP-Reihe | Korrigierte Veröffentlichung vom 21. Oktober 2026 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
1. Alle tatsächlich verwendeten PHP-Installationen erfassen
Eine Serverumgebung kann mehrere PHP-Versionen enthalten. Hinzu kommen Container, Hosting-Panel-Pakete und in andere Produkte integrierte Laufzeiten.
Qualys weist in seiner Analyse vom 21. Oktober 2026 ausdrücklich darauf hin, dass die Ausgabe von php -v zu einer anderen Installation gehören kann als derjenigen, die Webanfragen verarbeitet. [3]
Für Administratoren sind diese Befehle ein erster, rein lesender Einstieg:
Rein lesende Diagnosebefehle: php -v; php --ini Sie zeigen die Version des aufgerufenen PHP-Programms und dessen geladene Konfigurationsdateien. Sie belegen nicht allein, welche Version eine bestimmte Website oder ein bereits laufender Hintergrundprozess verwendet. Die Befehlsoptionen sind im PHP-Handbuch dokumentiert. [4]
Ich würde deshalb jede produktive Website ihrem konkreten PHP-Handler, Dienst oder Container zuordnen. Auch Testseiten und alte Subdomains gehören in diese Bestandsaufnahme, wenn sie weiterhin erreichbar sind.
2. Nicht korrigierbare Systeme vorübergehend abschirmen
Wenn sich ein exponiertes System nicht zeitnah aktualisieren lässt, empfiehlt CERT-EU, eine vorübergehende Trennung vom öffentlichen Netz zu erwägen, bis die Korrektur installiert und überprüft ist. [2]
Dabei ist ein Wartungsmodus innerhalb des CMS kein verlässlicher Ersatz. Unter Apache mit mod_php kann ein bestätigter Angriffsweg bereits vor dem eigentlichen Anwendungscode ansetzen. Eine entsprechende Schutzentscheidung muss daher vor der gefährdeten PHP-Verarbeitung greifen. [5]
Praktisch würde ich eine statische Wartungsseite außerhalb der betroffenen PHP-Anwendung oder eine kontrollierte Zugangsbeschränkung auf vorgeschalteter Ebene vorsehen.
Welche Variante geeignet ist, muss die Administration anhand der Umgebung entscheiden. Ein gewöhnlicher Websitebetreiber sollte nicht auf Verdacht Firewallregeln verändern und dabei möglicherweise andere Dienste blockieren.
3. Den richtigen Updateweg verwenden
Beim Webhosting ist zunächst der Anbieter zuständig, soweit dieser die PHP-Laufzeit verwaltet. Bei einem eigenen Server erfolgt das Update über die dafür vorgesehene Paketquelle oder das Verwaltungsverfahren der Plattform.
Wichtig ist die vollständige Paketversion, nicht nur die kurze PHP-Nummer.
Ein konkretes Beispiel: Ubuntu führt für 24.04 LTS das Paket 8.3.6-0ubuntu0.24.04.13 als korrigiert auf. Obwohl darin weiterhin „8.3.6“ steht, enthält dieses Ubuntu-Paket die Sicherheitskorrekturen. Eine Bewertung allein anhand der upstream-Versionstabelle wäre hier falsch. [6]
Für mich folgt daraus: Die installierte Paketkennung muss mit der Sicherheitsmeldung der tatsächlich verwendeten Distribution verglichen werden. Ein beliebiger Versionsvergleich aus einem Forum reicht dafür nicht.
Bei Plesk beschreibt der Anbieter ebenfalls Sonderfälle, in denen korrigierte ältere PHP-Ausgaben dieselbe PHP-Versionsnummer behalten, aber einen neuen Build-Stand besitzen. Außerdem unterscheidet Plesk die PHP-Installationen der Websites von der internen PHP-Komponente sw-engine seiner Verwaltungsoberfläche. Deren Korrektur muss separat anhand der aktuellen Plesk-Meldung geprüft werden; ein aktualisierter Website-Handler allein ist dafür kein Nachweis. [7]
4. Sicherung und Rückweg vorbereiten, ohne den Patch unnötig zu verzögern
Vor dem Eingriff würde ich die aktuelle Konfiguration, benötigte Daten und den vorgesehenen Wiederherstellungsweg sichern beziehungsweise kontrollieren.
Das darf aber nicht dazu führen, ein gefährdetes öffentliches System noch stundenlang unverändert erreichbar zu lassen, während ein aufwendiger Probelauf organisiert wird. Im Zweifel wird zuerst die Erreichbarkeit begrenzt.
Besteht bereits ein Angriffsverdacht, würde ich Protokolle und relevante Zustände erhalten und fachkundige Unterstützung einbeziehen. Ein neu erzeugtes Backup ist dann nicht automatisch ein nachweislich sauberer Wiederherstellungsstand.
Auch der Rückweg braucht eine Grenze: Nach einem fehlgeschlagenen Update darf eine ungepatchte Altversion nicht einfach wieder öffentlich erreichbar werden. Die Wiederherstellung muss mit einer wirksamen Korrektur oder weiterer Abschirmung verbunden werden.
5. Laufende Dienste und Hintergrundprozesse erneuern
Nach dem Paketupdate muss geprüft werden, welche Prozesse die alte Laufzeit noch im Speicher haben.
Laravel Forge weist in seiner aktuellen Anleitung ausdrücklich darauf hin, dass länger laufende PHP-Prozesse nach einem Paketupdate die bisherige Version weiterverwenden können. Dazu zählen beispielsweise Warteschlangenprozesse und Dienste für dauerhaft laufende Anwendungen. Diese müssen gesondert neu gestartet werden. [8]
Je nach Betriebsart betrifft das PHP-FPM, den Webserver mit eingebundenem PHP, Anwendungsdienste oder die erneute Bereitstellung von Containern.
Ich würde nicht nur einen Container neu starten, wenn dessen Image weiterhin die ungepatchte Software enthält. Zunächst muss der korrigierte Softwarestand in das bereitgestellte Image gelangen. Auch Qualys nennt die Aktualisierung beziehungsweise Neuerstellung der Images und die anschließende Erneuerung der laufenden Instanzen ausdrücklich. [3]
Der Abschlussnachweis muss daher den laufenden Betrieb einbeziehen – nicht lediglich die Erfolgsmeldung des Paketmanagers.
6. Notfallkonfigurationen nicht mit einer vollständigen Behebung verwechseln
Im Internet werden verschiedene Übergangsmaßnahmen genannt. Einige davon stammen tatsächlich aus den offiziellen Hinweisen, wirken aber nur gegen bestimmte Varianten.
Dazu gehören beispielsweise das Abschalten der Upload-Fortschrittsverarbeitung mit session.upload_progress.enabled=0 und unter PHP 8.5 das Deaktivieren bestimmter Fehler-Backtraces. Solche Einstellungen müssen rechtzeitig vor der Anfrageverarbeitung greifen; eine Änderung erst im Anwendungscode genügt für die beschriebenen Schutzwirkungen nicht. [5]
Besondere Vorsicht gilt bei memory_limit=-1. Die Einstellung hebt die PHP-eigene Speicherbegrenzung auf. Sie kann einen bestimmten Fehlerpfad erschweren, lässt aber weitere Risiken bestehen und kann Ressourcenerschöpfung begünstigen. Sie ist keine allgemeine Empfehlung zum bedenkenlosen Kopieren. [3][5]
Für normale Betreiber ist der korrigierte PHP-Stand der richtige Weg. Übergangskonfigurationen gehören in die Hände der zuständigen Administration.
Nach erfolgreicher Korrektur sollten vorübergehende Einschränkungen nochmals bewertet und kontrolliert zurückgenommen werden. Insbesondere sollte eine vorübergehend aufgehobene PHP-Speicherbegrenzung wieder auf einen zum Betrieb passenden endlichen Wert gesetzt werden, nachdem die korrigierte Laufzeit nachgewiesen ist. Auch das Verhalten bei Speichermangel gehört in die Funktionsprüfung. [3]
7. Funktion und Sicherheitsstand getrennt prüfen
Nach dem Update würde ich zunächst wenige wichtige Abläufe testen: Seitenaufruf, Anmeldung, Formularverarbeitung, benötigte Uploads und die wesentlichen Hintergrundaufgaben.
Diese Funktionsprüfung beantwortet, ob die Anwendung weiterhin arbeitet. Sie ersetzt nicht den Nachweis, dass alle verwendeten PHP-Instanzen korrigiert sind.
Zum Abschluss sollten für jede betroffene Anwendung Paketstand, Updatezeitpunkt, erneuerte Dienste und Prüfergebnis dokumentiert sein. Nicht mehr benötigte Installationen würde ich entfernen oder dauerhaft stilllegen, statt sie unbemerkt für einen späteren Einsatz bereitzuhalten.
Was bei einem möglichen Einbruch zusätzlich nötig ist
Ein Update schließt die Schwachstelle. Es entfernt nicht automatisch eine zuvor hinterlegte Hintertür.
Das NCSC empfiehlt ausdrücklich, bei nicht rechtzeitig aktualisierten oder abgeschalteten Systemen nach Hinweisen auf eine Kompromittierung und nach installierten Hintertüren zu suchen. Wo die eigenen Kenntnisse dafür nicht ausreichen, sollte spezialisierte Unterstützung hinzugezogen werden. [9]
Welche Zugangsdaten gegebenenfalls erneuert und welche Systeme wiederhergestellt werden müssen, hängt von den Untersuchungsergebnissen ab. Eine pauschale Entwarnung nach einem erfolgreichen Paketupdate wäre bei konkretem Angriffsverdacht nicht ausreichend.
Mein Fazit: Erledigt ist die Aufgabe erst nach der Kontrolle
Eine effiziente Reaktion besteht nicht aus möglichst vielen Änderungen. Sie besteht aus den richtigen Änderungen an den richtigen Stellen.
Betroffene Anwendung zuordnen, passenden Patch installieren, laufende Prozesse erneuern und das Ergebnis nachweisen: Erst diese Kette macht aus einer Update-Meldung eine tatsächlich abgeschlossene Sicherheitsmaßnahme.
Einordnung dieses Beitrags
Die Anleitung dient der allgemeinen Orientierung. Paketnamen, Verwaltungswege und Neustarts unterscheiden sich je nach Betriebssystem und Hostingumgebung. Änderungen an produktiven Systemen müssen durch zuständige Fachkräfte erfolgen. Die Hinweise ersetzen weder eine individuelle Betriebsplanung noch die Untersuchung eines möglichen Einbruchs.
Quellen und weiterführende Informationen
Recherchestand: 21. Oktober 2026. Herstellerangaben und veröffentlichte Untersuchungen sind keine eigene Prüfung der hier beschriebenen Systeme.
[1] PHP-Projekt – Sicherheitsveröffentlichungen vom 21. Oktober 2026:
Quelle lesen ↗
[2] CERT-EU – Empfehlungen zu Aktualisierung und vorübergehender Isolation:
Quelle lesen ↗
[3] Qualys – Updatekontrolle, laufende Instanzen und Grenzen von Übergangsmaßnahmen:
Quelle lesen ↗
[4] PHP-Handbuch – Kommandozeilenoptionen:
Quelle lesen ↗
[5] PHP-Sicherheitsmeldungen – technische Abgrenzung der Übergangsmaßnahmen:
Quelle lesen ↗
[5] PHP-Sicherheitsmeldungen – technische Abgrenzung der Übergangsmaßnahmen:
Quelle lesen ↗
[6] Ubuntu – Sicherheitsmeldung USN-8948-1
Quelle lesen ↗
[7] Plesk – Betroffene Komponenten, korrigierte Versionen und Build-Stände:
Quelle lesen ↗
[8] Laravel Forge – PHP-Sicherheitsupdate und Neustart langfristig laufender Prozesse:
Quelle lesen ↗
[9] NCSC – Prioritäten und Untersuchung möglicher Kompromittierungen:
Quelle lesen ↗
Weitere Beiträge dieser Reihe
PHP2Shell · Teil 1
Quelle lesen ↗
PHP2Shell · Teil 3
Quelle lesen ↗