PHP2Shell: Wie wir rund 100 Websites auf PHP 8.1 bis 8.5 abgesichert haben

Am Abend des 20. Oktober 2026 tauchte in einem Forum ein Beitrag über zwei kritische PHP-Lücken auf, der kurz darauf wieder gelöscht wurde. Wenige Stunden später kündigte das PHP-Sicherheitsteam einen Notfall-Release für den nächsten Tag an. Für uns als Agentur mit rund 100 betreuten Websites war damit klar, dass der nächste Tag kein normaler Arbeitstag werden würde. Dieser Beitrag beschreibt, wie wir PHP2Shell in der Praxis erlebt haben: welche Systeme wir im Blick hatten, was automatisch lief, wo wir von Hostern abhängig waren und was wir daraus für die tägliche Arbeit mitnehmen.

Eine technische Einordnung der Lücken, Prüfbefehle für verschiedene Betriebssysteme und eine Übersicht der Hoster-Stellungnahmen finden Sie in unserem Fachartikel auf webnotaufnahme.de zu PHP2Shell und den beiden CVEs. Hier geht es um die Erfahrung aus dem Agenturalltag.

Was PHP2Shell für Websitebetreiber bedeutet

PHP2Shell ist der Name für zwei Sicherheitslücken in PHP selbst, CVE-2026-109618 und CVE-2026-109619. Beide wurden mit einem CVSS-Wert von 9,2 als kritisch eingestuft und können laut Advisory dazu führen, dass fremder Code auf dem Server ausgeführt wird, ohne dass ein Login nötig ist. Behoben sind sie in den PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35, die am 21. Oktober 2026 um 14:00 UTC erschienen sind. Die Ankündigung des PHP-Teams finden Sie in den php.announce-Mitteilungen, eine unabhängige Einordnung bei Help Net Security.

Für Betreiber ist ein Punkt entscheidend: Die Lücke sitzt nicht in WordPress, TYPO3 oder Laravel, sondern darunter. Ein tadellos gepflegtes CMS mit aktuellen Plugins hilft nicht, wenn die PHP-Version auf dem Server veraltet ist. Genau deshalb betraf das Thema bei uns alle Systeme gleichermaßen, egal ob WordPress, TYPO3, Laravel oder ein kleines Individualprojekt.

Für PHP 8.1 und älter gibt es keinen regulären Release mehr. Dort hängt der Schutz davon ab, ob Hoster oder Betriebssystem-Hersteller einen Backport anbieten. Diese Unterscheidung hat unseren Ablauf am stärksten geprägt.

Unsere Ausgangslage: rund 100 Websites auf PHP 8.1 bis 8.5

Wir betreuen als Agentur Websites und Webanwendungen auf sehr unterschiedlichen Plattformen. Auf der CMS-Seite sind das vor allem WordPress und TYPO3, dazu kommen Laravel-Anwendungen und weitere PHP-Projekte. Die eingesetzten PHP-Versionen reichen von 8.1 bis 8.5, weil Projekte unterschiedlich alt sind und Updates bei großen Seiten bewusst geplant werden.

Gehostet ist das Ganze nicht an einer Stelle. Wir arbeiten mit zahlreichen Hostern, die wir aus Kundenprojekten gut kennen: HostEurope, Mittwald, All-Inkl, DomainFactory, Strato, Ionos und Hetzner. Dazu kommen eigene Server, die wir selbst betreiben. Für die Frage, wer bei PHP2Shell am Zug ist, ergibt das drei Gruppen.

Bei der ersten Gruppe wählen wir die PHP-Version selbst im Kundenbereich des Hosters oder auf dem Server. Bei der zweiten Gruppe spielt der Hoster die Patch-Version ein, und wir können nur prüfen, ob es geschehen ist. Bei der dritten Gruppe, den eigenen Servern, liegt die Verantwortung komplett bei uns. Wer eine solche Landkarte vorher nicht hat, verliert in einer Lage wie dieser die ersten Stunden mit Suchen.

Der Ablauf bei uns: prüfen, aktualisieren, nachhaken

Direkt nach Veröffentlichung des Fixes haben wir begonnen, die PHP-Versionen aller Websites zu prüfen. Wo wir selbst Hand anlegen konnten, haben wir sofort aktualisiert. Wo die Versionswahl oder das Einspielen beim Hoster lag, mussten wir einen anderen Weg gehen. Die folgende Tabelle zeigt, wie wir je nach Situation vorgegangen sind.

Der letzte Punkt war die unangenehmste Entscheidung. Einzelne Websites haben wir bewusst für kurze Zeit offline genommen, weil der Hoster zu diesem Zeitpunkt noch nicht gepatcht hatte und wir selbst keine Möglichkeit hatten, die PHP-Version anzuheben. Das fühlt sich für Kunden zunächst drastisch an. Bei einer kritischen Lücke ohne Login-Voraussetzung, bei der Sicherheitsfirmen schnelle Massenversuche nach Veröffentlichung des Patches erwarten, war es für uns aber die vertretbare Entscheidung. Eine kurz nicht erreichbare Website lässt sich erklären, eine übernommene Website deutlich schwerer.

Wichtig war dabei die Kommunikation. Wir haben betroffene Kunden informiert, bevor sie selbst etwas bemerken konnten, und die Seiten wieder freigegeben, sobald der Hoster nachgezogen hatte und die Version bestätigt war. Eine Bestätigung der Hoster-Seite nehmen wir dabei nicht als gegeben hin, sondern prüfen die laufende Version nach.

Warum vieles automatisch lief: Laravel Forge und professionelle Prozesse

Ein großer Teil der Arbeit blieb uns erspart, weil wir viele Server nicht von Hand verwalten. Mit Werkzeugen wie Laravel Forge lassen sich PHP-Updates über mehrere Server hinweg anstoßen, ohne dass jemand per SSH auf jede Maschine muss. Wer einmal an einem Tag mit kritischer Lücke zwanzig Server nacheinander von Hand aktualisiert hat, weiß den Unterschied zu schätzen.

Zwei Dinge sollten Sie dabei nicht vergessen, auch wenn das Einspielen automatisiert ist. Erstens reicht das Paket-Update allein nicht, denn laufende PHP-Prozesse nutzen die alte Version, bis sie neu gestartet werden. Bei Laravel-Projekten gilt das auch für Queue-Worker. Zweitens muss geprüft werden, welche Version der Webserver tatsächlich ausführt, denn die Kommandozeile kann eine andere PHP-Version nutzen als der Webserver. Die folgenden Befehle gehören bei uns zur Routine:

# Version der Kommandozeile
php -v

# Version, mit der PHP-FPM läuft
php-fpm8.3 -v

# Laravel: Queue-Worker mit neuem Code neu starten
php artisan queue:restart

Der Befehl für den FPM-Dienst hängt von der installierten Version ab und muss entsprechend angepasst werden. Wichtig ist das Prinzip: Nach einem Update wird nicht angenommen, sondern nachgesehen.

Ausfälle im Blick: Monitoring mit Pingoclock

Wenn man Seiten kurzfristig vom Netz nimmt, PHP-Prozesse neu startet und Versionen wechselt, entstehen zwangsläufig Momente, in denen etwas nicht mehr so läuft wie vorher. In einer solchen Lage ist ein Überblick über alle Websites wichtiger als jede Einzelmaßnahme. Wir nutzen dafür Pingoclock, unser eigenes Monitoring, das wir auch an Kunden vertreiben. Damit hatten wir alle Ausfälle im Blick, egal ob sie von uns gewollt waren oder durch ein Update unbeabsichtigt entstanden sind.

Gerade bei PHP-Updates auf Produktivsystemen ist das der Unterschied zwischen „wir haben gepatcht“ und „wir wissen, dass alles danach noch läuft“. Eine Website, die nach einem Versionssprung einen Fehler 500 liefert, ist zwar abgesichert, aber nicht mehr erreichbar. Ohne Überwachung erfährt man das oft erst vom Kunden.

Backups als Sicherheitsnetz

Ein weiterer Baustein war unsere Backup-Lösung. Sie hat kurz vor der Bekanntgabe der Lücke noch reguläre Backups erstellt. Das ist kein Zufall, sondern Ergebnis regelmäßiger Sicherungen, aber in dieser Lage war es ein beruhigender Zustand: Selbst wenn eine Website vor dem Update übernommen worden wäre, hätten wir einen sauberen Stand von unmittelbar vor der Bekanntgabe gehabt, auf den wir hätten zurückgehen können.

Das ist ein Punkt, der bei PHP2Shell besonders zählt. Ein PHP-Update schließt die Lücke, entfernt aber keine Hintertür, die bereits installiert wurde. Wer einen Stand aus der Zeit vor der Veröffentlichung hat, kann im Zweifel vergleichen, ob sich seitdem unerwartet Dateien verändert haben. Ein Backup, das nur wenige Stunden alt ist, hilft in dieser Situation mehr als jede nachträgliche Vermutung.

Was wir aus PHP2Shell mitnehmen

Aus dieser Lage lassen sich einige Erkenntnisse ziehen, die über den Anlass hinaus gelten und die wir auch Kunden empfehlen, die ihre Website selbst betreiben oder bei einem Hoster haben.

Die wichtigste Erkenntnis ist, dass Bestandsaufnahme vor Reaktion kommt. Wer weiß, welche Website auf welchem Server mit welcher PHP-Version läuft, kann in Stunden handeln. Wer es nicht weiß, braucht dafür Tage. Wir pflegen deshalb eine Übersicht aller Projekte mit Hoster, PHP-Version und Zuständigkeit, und die Lage hat uns bestätigt, wie wertvoll diese Liste ist.

Die zweite Erkenntnis betrifft veraltete PHP-Versionen. Wer noch auf PHP 8.1 oder älter unterwegs ist, ist bei einer Lücke wie dieser vom guten Willen des Hosters abhängig. Ein regelmäßiges Aktualisieren der PHP-Version, wie es auch Suchanfragen wie „PHP Version aktualisieren“ oder „PHP Update WordPress“ zeigen, ist deshalb keine Kür, sondern Teil der Grundpflege. Beim Wechsel auf eine neuere Version sollten Sie vorher ein Backup anlegen, Plugins und Theme aktualisieren und die Seite idealerweise auf einer Kopie testen.

Die dritte Erkenntnis ist, dass Automatisierung und Monitoring zusammengehören. Automatische Updates sparen Zeit, aber erst die Überwachung zeigt, ob danach noch alles funktioniert. Und viertens: Wer Hoster-Aussagen vertraut, sollte sie trotzdem prüfen. „Wir kümmern uns“ ist keine Versionsnummer.

Was Sie als Websitebetreiber jetzt tun sollten

Wenn Sie nicht sicher sind, wie es um Ihre Website steht, gehen Sie in drei Schritten vor. Prüfen Sie zuerst die PHP-Version, mit der Ihre Seite tatsächlich läuft. Bei WordPress finden Sie sie im Backend unter Werkzeuge im Bereich Website-Zustand, in anderen Systemen im Kundenbereich des Hosters. Fragen Sie danach beim Hoster schriftlich nach, ob und wann der Fix für Ihren Tarif eingespielt wurde. Und stellen Sie drittens sicher, dass Sie ein aktuelles Backup haben, das sich auch wiederherstellen lässt.

Läuft Ihre Seite auf PHP 8.1 oder älter, sollten Sie den Wechsel auf eine unterstützte Version zügig planen, in der Regel auf PHP 8.3 oder 8.4. Sie sollten auch Ihre Seite im Blick behalten, etwa auf unbekannte Administratoren oder neue PHP-Dateien im Upload-Ordner, denn ein Update entfernt keine bereits installierte Hintertür.

Wenn Sie das nicht selbst stemmen wollen

Bei rund 100 Websites haben wir gesehen, wie schnell aus einer einzigen PHP-Lücke ein Koordinationsthema wird, wenn Hoster, Versionen und Zuständigkeiten verteilt sind. Bei einer einzelnen Unternehmenswebsite ist der Aufwand kleiner, die Unsicherheit aber oft größer, weil die Ansprechpartner fehlen. Genau dafür sind wir da: Wir prüfen Ihre PHP-Version und Ihren Hoster, spielen Updates ein, wo es möglich ist, und halten Ihre Seite im Blick. Wenn Sie wissen möchten, wie es um Ihre Website steht, sprechen Sie uns gerne an.