AKTUELLE SICHERHEITSLÜCKE
Am 20. Oktober 2026 kündigte das PHP-Projekt ein außerplanmäßiges Sicherheitsupdate an – ohne technische Details, aber mit zwei CVE-Nummern und der Bewertung „kritisch“. Rund zwanzig Stunden später war der Patch da. In der Zwischenzeit kursierten die Details bereits öffentlich, samt einem Werkzeug, das den Angriff vorführte. Für Betreiber bedeutete das ein Zeitfenster, in dem es keinen wirksamen Schutz gab – nur eine Entscheidung.
Wir haben uns in dieser Nacht entschieden, betroffene Dienste abzuschalten. Dieser Beitrag erklärt, warum das die richtige Wahl war, was php2shell technisch bedeutet und was jetzt zu tun ist.
Was ist php2shell? Die Kurzantwort
php2shell ist der Sammelname für zwei kritische Schwachstellen im Kern der Programmiersprache PHP: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2 bewertet. Sie erlauben es einem Angreifer, ohne Anmeldung und aus der Ferne eigenen Code auf dem Webserver auszuführen. Betroffen sind alle PHP-Installationen, die Webanfragen verarbeiten – Apache mit mod_php, PHP-FPM, php-cgi, LiteSpeed und FrankenPHP. Die Fehler reichen laut PHP-Projekt bis in PHP-Versionen von vor zwanzig Jahren zurück. Geschlossen sind sie seit dem 21. Oktober 2026 in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das BSI führt die Lücken mit Kritikalität 3 (Orange) und riet Betreibern, Server im Zweifel vom Internet zu trennen, weil Übergangsmaßnahmen keinen vollständigen Schutz bieten.
Warum Abschalten die einzige wirksame Maßnahme war
Bei den meisten Sicherheitslücken gibt es einen Mittelweg: eine Firewall-Regel, eine Konfigurationsänderung, eine Schnittstelle sperren. Bei php2shell war dieser Mittelweg nicht verfügbar – und das ist der entscheidende Unterschied zu fast allem, was wir sonst sehen.
Die Lücke sitzt im PHP-Kern selbst, in der Speicherverwaltung. Sie greift, bevor die eigentliche Anwendung startet. Ein WordPress-Update hilft nicht, ein Sicherheitsplugin hilft nicht, und auch eine Web Application Firewall kann die Angriffsmuster nur teilweise erkennen – anders als bei Lücken, die in einer bestimmten Schnittstelle sitzen und sich gezielt sperren lassen.
Das PHP-Team selbst bezeichnete die veröffentlichten Konfigurationsempfehlungen ausdrücklich als Übergangslösung, nicht als Schutz. Das BSI formulierte es noch deutlicher und empfahl, bei nicht sofort patchbaren Servern eine vorübergehende Trennung vom Internet zu erwägen.
Genau das haben wir getan. Für den Zeitraum zwischen Bekanntwerden und verfügbarem Patch haben wir betroffene Dienste vom Netz genommen – nicht als Panikreaktion, sondern weil die Rechnung eindeutig war: Ein paar Stunden geplante Nichterreichbarkeit sind beherrschbar. Ein übernommener Webserver ist es nicht.
Wir waren damit nicht allein. Auch die Charité, die Stadt Mainz und mehrere Hosting-Anbieter nahmen Webauftritte vorübergehend offline.
Warum das Zeitfenster so gefährlich war
Normalerweise liegt zwischen Patch und funktionierendem Exploit eine Weile. Hier war es umgekehrt: Die technischen Details und ein vorführbares Angriffswerkzeug waren bereits öffentlich, bevor das Update erschien.
Das kehrt die übliche Logik um. Wer wartet, bis der Patch da ist, um dann in Ruhe zu planen, hat das kritische Fenster bereits verpasst. Sicherheitsdienstleister beobachteten noch am Tag des Updates erste Angriffsversuche; ein großer Netzwerkanbieter schaltete vorsorglich Filterregeln für alle Kunden.
Der Patch ist selbst die Bauanleitung
Hier liegt der Punkt, der in der Diskussion am häufigsten untergeht – und der erklärt, warum Tempo beim Einspielen so entscheidend ist.
Ein Sicherheitsupdate ist öffentlich einsehbarer Quellcode. Wer die gepatchte Version mit der Vorversion vergleicht, sieht exakt, welche Zeilen geändert wurden. Daraus lässt sich rückwärts ableiten, worin der Fehler bestand und wie er sich auslösen lässt. Fachleute nennen das Patch-Diffing.
Das bedeutet in der Praxis: Angreifer, die die Lücke vorher gar nicht kannten, bekommen mit der Veröffentlichung des Patches eine Anleitung frei Haus. Der Patch schützt alle, die ihn einspielen – und bewaffnet alle, die ihn lesen. Für jedes System, das nicht aktualisiert wurde, steigt das Risiko ab diesem Moment nicht allmählich, es springt.
Früher war das ein Wettlauf über Tage bis Wochen: Aus einem Patch einen funktionierenden Exploit zu rekonstruieren, war Spezialistenarbeit. Dieser Puffer ist weg. KI-Werkzeuge analysieren Code-Unterschiede inzwischen in Minuten, formulieren eine Angriffshypothese und erzeugen den passenden Testcode gleich mit. Was früher erfahrene Reverse-Engineers beschäftigte, läuft heute automatisiert – und skaliert, weil anschließend ebenso automatisiert das halbe Internet nach verwundbaren Systemen durchsucht wird.
Bei php2shell kam beides zusammen: Die Details waren schon vor dem Patch geleakt, und der Patch lieferte die Bestätigung nach. Wer in diesem Fenster zu langsam war, stand nicht einem theoretischen Risiko gegenüber, sondern laufenden, automatisierten Scans.
Die praktische Konsequenz: Bei kritischen Lücken zählt nicht der Patch-Zyklus, sondern die Reaktionszeit. Ein monatliches Wartungsfenster ist für den Normalbetrieb richtig und für einen Fall wie diesen unbrauchbar.
Was jetzt zu tun ist
- PHP-Version prüfen. Sicher sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder neuer. Verlassen Sie sich nicht auf die Paketversion allein – prüfen Sie das Änderungsprotokoll des Pakets auf die CVE-Nummer.
- Update einspielen und PHP-Worker neu starten. Ohne Neustart der Prozesse läuft die alte, verwundbare Version weiter. Das wird regelmäßig übersehen.
- Version nach dem Neustart über den Webserver verifizieren, nicht nur auf der Kommandozeile. Beides kann auseinanderlaufen.
- Logs prüfen. Eine verwundbare Installation bedeutet nicht automatisch einen erfolgreichen Angriff – aber die Frage gehört beantwortet. Achten Sie auf ungewöhnlich viele Anfragen in kurzer Zeit: Die bekannten Exploits brauchen oft mehrere tausend Versuche, bis sie greifen. Das ist im Log sichtbar.
- Auf Spuren sehen. Neu hinzugekommene oder veränderte PHP-Dateien, unbekannte Administratorkonten, auffällige geplante Aufgaben.
Falls Sie dabei etwas finden: nicht neu starten, nicht löschen, nicht überschreiben. Was im Ernstfall zu tun ist, haben wir separat beschrieben. Im akuten Verdachtsfall erreichen Sie uns unter +49 5362 975 28 66.
Lagebild: Wann ein System wirklich erledigt ist
Ein Patch beantwortet nur eine von zwei Fragen. Er schließt die Lücke für die Zukunft – aber er sagt nichts darüber, ob in den Stunden davor schon jemand eingedrungen ist. Eine Webshell oder ein angelegtes Administratorkonto übersteht jedes Update. Wir führen jedes System deshalb auf zwei getrennten Achsen.
Achse 1: Patchstand – ist die Lücke zu?
- Gepatcht: Korrigierte Version installiert und PHP-Prozesse neu gestartet, laufende Version über den Webserver bestätigt.
- Patch offen: Ein Update existiert, ist aber nicht eingespielt. Das muss sofort behoben werden, bis dahin gilt: abschalten.
- Warten auf Hersteller: Für die Plattform gibt es noch kein Update. Status täglich prüfen, Prüfung dokumentieren.
- Version zu alt: Kein Update zu erwarten. Es bleibt nur Migration, Abschalten oder eine bewusste Risikoentscheidung (siehe nächster Abschnitt).
Achse 2: Integrität – war schon jemand drin?
- Ungeprüft: Standard für jedes System, das seit dem 20. Oktober aus dem Internet erreichbar war – auch für bereits gepatchte.
- Geprüft, sauber: Alle Kriterien unten erfüllt und dokumentiert.
- Verdacht: Ab hier gilt der Vorfallprozess, nicht mehr der Patchprozess.
Der Gesamtstatus ist immer der schlechtere der beiden Werte. Ein gepatchtes, aber ungeprüftes System ist nicht erledigt. Und: Ein unbekannter Zustand zählt nie als gut – fehlt die Information zum Patchstand, gilt er als offen; fehlt die Prüfung, gilt das System als ungeprüft. Wer mehrere Standorte oder Mandanten verantwortet, bewertet jede Einheit nach ihrem schlechtesten System: Neun saubere Websites und ein ungeprüftes Altsystem ergeben keinen grünen Haken.
Wann die Integrität sichergestellt ist
Ein System gilt erst dann als geprüft sauber, wenn alle folgenden Bedingungen erfüllt sind:
- Das Prüffenster ist vollständig abgedeckt: vom 20. Oktober 2026 bis zu dem Zeitpunkt, an dem die gepatchte Version nach dem Neustart tatsächlich lief. Zeiten, in denen das System abgeschaltet war, verkürzen dieses Fenster – auch das spricht für frühes Abschalten.
- Die Logs liegen für das gesamte Fenster vor und sind unauffällig: keine Häufungen gleichartiger Anfragen, keine Serien von Speicherfehlern oder abgestürzten PHP-Prozessen.
- Das Dateisystem ist unverändert: keine neuen oder veränderten PHP-Dateien, insbesondere in Upload-, Cache- und Temp-Verzeichnissen.
- Konten und Aufgaben sind bekannt: nur bekannte Administratoren in Anwendung und Hosting-Panel, keine neuen SSH-Schlüssel, keine fremden Cronjobs oder geplanten Aufgaben.
- Der Netzwerkverkehr ist unauffällig: keine ungewöhnlichen ausgehenden Verbindungen des Webservers.
- Ein vollständiger Malware-Scan ist ohne Fund durchgelaufen.
- Die Prüfung ist dokumentiert: wer, wann, mit welchem Ergebnis. Was nicht dokumentiert ist, lässt sich gegenüber Auditoren, Versicherern oder Behörden nicht belegen.
Zwei Fälle, die oft falsch eingeordnet werden: Fehlen die Logs für einen Teil des Fensters – etwa weil sie bereits rotiert wurden –, ist die Integrität nicht nachweisbar. Das System gilt dann nicht als sauber. Mindestens rotieren Sie alle Zugangsdaten (Datenbank, API-Schlüssel, Salts) und überwachen das System engmaschig; bei Systemen mit sensiblen oder personenbezogenen Daten setzen Sie es neu auf. Dasselbe gilt, wenn die Logs Angriffsversuche zeigen, die übrige Prüfung aber nichts findet: Ein erfolgreicher Angriff hinterlässt nicht zwingend Dateien. Zugangsdaten rotieren ist hier Pflicht, nicht Kür.
Erledigt ist ein System erst, wenn beide Achsen grün sind.
Wenn Sie auf PHP 8.1 oder älter laufen
Für PHP 8.1 und ältere Zweige gibt es vom PHP-Projekt kein offizielles Update. Diese Versionen haben ihr Lebensende erreicht. Wer dort steht, hat keine Patch-Option, sondern eine Migrationsaufgabe – und bis dahin ein dauerhaft offenes Risiko.
Bis zur Migration gibt es genau drei Wege: aktualisieren, vom Netz nehmen oder das Risiko bewusst tragen. Der dritte Weg ist legitim, aber nur als dokumentierte Entscheidung der Geschäftsführung – schriftlich, mit Ablaufdatum und begleitender Überwachung. Eine Risikoakzeptanz ohne Datum ist keine Entscheidung, sondern eine vergessene Lücke. Und auch ein akzeptiertes Risiko entbindet nicht von der Integritätsprüfung.
Auch wer aktuell abgesichert ist, sollte den Kalender im Blick behalten: PHP 8.2 erhält nur noch bis Ende 2026 Sicherheitsupdates, PHP 8.3 bis Ende 2027. Eine veraltete PHP-Version ist kein Schönheitsfehler, sondern ein planbarer Ausfall der Sicherheitsversorgung.
Was dieser Vorfall über Hosting aussagt
php2shell hat eine Frage sehr schnell beantwortet: Wer entscheidet um drei Uhr nachts?
Bei Standard-Webhosting lautet die Antwort oft: niemand, der Ihre Website kennt. Entweder der Anbieter patcht irgendwann im Laufe des Tages, oder Sie müssen selbst eingreifen – und zwar in einem Zeitfenster, das Sie nicht gewählt haben und in dem die Entscheidung zwischen „Abschalten“ und „Risiko aussitzen“ getroffen werden muss.
Unser Managed Hosting ist auf genau diesen Fall gebaut:
- Wir entscheiden und handeln, ohne dass Sie ein Ticket aufmachen müssen. Bei php2shell hieß das: abschalten, patchen, prüfen, wieder online.
- Isolierte Umgebungen: Eine kompromittierte Installation reißt nicht die Nachbarn mit. Bei vielen günstigen Shared-Hostern ist genau das der Normalfall.
- Serverseitiger Schutz mit virtuellem Patchen und Malware-Scanning im Dauerbetrieb – wirksam gegen die Angriffsklassen, bei denen es wirkt, und ehrlich benannt, wo es wie hier an Grenzen stößt.
- Gepflegte PHP-Versionen: Kein Kunde läuft unbemerkt in ein End-of-Life.
- Tägliche Sicherung außerhalb des Servers: Ein Backup auf demselben System ist im Ernstfall genauso kompromittiert wie die Website.
Ein ähnliches Muster haben wir im Sommer bei der WordPress-Lücke wp2shell gesehen – dort ließ sich das Zeitfenster allerdings mit einer gezielten WAF-Regel überbrücken. Bei php2shell ging das nicht. Der Unterschied liegt in der Ebene: Eine Lücke in der Anwendung lässt sich davor abfangen, eine im Sprachkern nicht.
Häufige Fragen (FAQ)
Hilft ein WordPress-Update gegen php2shell? Nein. Die Lücke liegt in PHP, eine Ebene unter WordPress, und greift bereits bevor die Anwendung startet. WordPress-Updates bleiben wichtig, schließen aber diese Lücke nicht.
Reicht ein Sicherheitsplugin? Nein. Plugins arbeiten innerhalb von WordPress – also zu spät.
Mein Hoster sagt, er hat gepatcht. Bin ich sicher? Wenn tatsächlich eine der korrigierten Versionen läuft und die PHP-Prozesse neu gestartet wurden: gegen künftige Angriffe auf diese Lücke ja. Ob in der Zeit davor jemand eingedrungen ist, beantwortet der Patch nicht – das klärt erst die Integritätsprüfung. Lassen Sie sich beides bestätigen: die laufende Version und das Prüfergebnis.
Ab wann gilt ein System als sauber? Wenn das gesamte Zeitfenster seit dem 20. Oktober bis zum Neustart mit gepatchter Version geprüft ist – Logs, Dateien, Konten, geplante Aufgaben, Netzwerkverkehr und Malware-Scan – und nichts Auffälliges gefunden wurde. Fehlen Logs für diesen Zeitraum, ist die Integrität nicht nachweisbar; dann mindestens alle Zugangsdaten rotieren.
War das Abschalten übertrieben? Rückblickend war es die Empfehlung, die auch das BSI ausgesprochen hat. Bei einer Lücke ohne wirksamen Übergangsschutz, mit öffentlichem Exploit und ohne verfügbaren Patch gibt es keine dritte Option.
Der Patch ist doch da – warum ist es trotzdem dringend? Weil der Patch beide Seiten informiert. Aus dem Vergleich von alter und neuer Version lässt sich der Angriff rekonstruieren, inzwischen automatisiert in Minuten. Ein ungepatchtes System ist nach der Veröffentlichung also gefährdeter als davor, nicht weniger.
Wie erkenne ich, ob jemand versucht hat, die Lücke auszunutzen? Die kursierenden Exploits arbeiten nicht beim ersten Versuch, sondern brauchen oft tausende Anfragen. Ungewöhnliche Lastspitzen mit vielen ähnlichen Anfragen in kurzer Zeit sind daher ein Indiz, das sich im Webserver-Log finden lässt.
Fazit
php2shell war ungewöhnlich, weil es den bequemen Mittelweg nicht gab. Keine Regel, keine Einstellung, kein Plugin – nur Patchen oder Abschalten. Wir haben abgeschaltet, weil ein paar Stunden Nichterreichbarkeit kalkulierbar sind und ein übernommener Server nicht.
Die eigentliche Lehre liegt daneben: Solche Entscheidungen müssen innerhalb von Stunden fallen, nachts, ohne vollständige Informationslage. Das ist keine Frage der Technik, sondern der Zuständigkeit. Wer bei der nächsten Lücke dieser Art nicht selbst wach sein will, braucht jemanden, der es ist.
Unsicher, auf welcher PHP-Version Ihre Website läuft – oder wer bei der nächsten kritischen Lücke für Sie entscheidet? Managed Hosting von UBESAFE nimmt Ihnen genau das ab. Zum Einstieg: kostenloses Erstgespräch. Im akuten Verdachtsfall: +49 5362 975 28 66.