Am 21. Oktober 2026 standen zahlreiche Betreiber von Websites und Servern weltweit vor einer außergewöhnlichen Herausforderung: Zwei kritische Sicherheitslücken in PHP ermöglichten es potenziellen Angreifern, eigenen Code aus der Ferne auf verwundbaren Systemen auszuführen – ohne Anmeldung und unter Umständen, bevor die eigentliche Webanwendung überhaupt aktiv wurde.
Die unter den Bezeichnungen CVE-2026-109618 und CVE-2026-109619 geführten Schwachstellen erhielten jeweils einen CVSS-Score von 9,2 von 10. Unter dem Namen „PHP2Shell“ entwickelte sich die Sicherheitslücke innerhalb kürzester Zeit zu einem globalen Sicherheitsthema.
Auch wir mussten kurzfristig Entscheidungen treffen, die den Betrieb unserer Kunden unmittelbar betrafen. Wir informierten über die Bedrohungslage, schalteten unsere Websites und Verwaltungsoberflächen vorübergehend ab, installierten die verfügbaren Sicherheitsupdates und nahmen die betroffenen Systeme anschließend schrittweise wieder in Betrieb.
In diesem Beitrag blicken wir auf die Ereignisse zurück, erklären die technischen Hintergründe und erläutern, warum wir uns für die ergriffenen Maßnahmen entschieden haben.
Am 20. Oktober kündigte das PHP-Projekt die kurzfristige Veröffentlichung von Sicherheitsupdates für zwei kritische Schwachstellen an. Technische Einzelheiten waren zu diesem Zeitpunkt noch nicht offiziell verfügbar. Die Veröffentlichung der Patches war für den folgenden Tag um 16 Uhr deutscher Zeit angekündigt.
Die Bewertungen nach CVSS 4.0 ließen bereits früh auf ein erhebliches Risiko schließen: Beide Schwachstellen wurden mit 9,2 von 10 Punkten bewertet. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Bedrohung in seinem IT-Sicherheitshinweis als 3 / Orange ein. Diese Warnstufe bedeutet, dass unverzüglich Maßnahmen erforderlich sind und massive Beeinträchtigungen des Regelbetriebs möglich sind.
Noch vor der Veröffentlichung der offiziellen Patches gelangten technische Details zu den Schwachstellen an die Öffentlichkeit. Damit änderte sich die Risikosituation grundlegend: Potenzielle Angreifer konnten beginnen, die verfügbaren Informationen auszuwerten und daraus Angriffsmöglichkeiten abzuleiten, während zahlreiche Systeme noch verwundbar waren.
Am 21. Oktober veröffentlichte das PHP-Projekt schließlich die Sicherheitsupdates für die unterstützten Versionszweige. Mit den aktualisierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 wurden beide Schwachstellen behoben.
PHP gehört zu den grundlegenden Technologien des Internets. Die Programmiersprache kommt nicht nur in klassischen Websites und Content-Management-Systemen wie WordPress, TYPO3, Drupal oder Joomla zum Einsatz. Sie ist auch Bestandteil von Shopsystemen, Verwaltungsoberflächen und verschiedenen technischen Produkten, darunter Netzwerk- und Sicherheitskomponenten.
Eine Schwachstelle im PHP-Kern betrifft deshalb nicht nur eine einzelne Anwendung, sondern potenziell zahlreiche unterschiedliche Systeme und Einsatzbereiche.
Besonders kritisch war, dass beide Schwachstellen eine Remote Code Execution (RCE) ermöglichen konnten. Damit ist die Ausführung von Code gemeint, den ein Angreifer über eine Netzwerkverbindung einschleust. Je nach Konfiguration und Berechtigungen des betroffenen Systems kann dies weitreichende Folgen haben – von der Manipulation einer Website über den Zugriff auf vertrauliche Daten bis hin zur weiteren Ausbreitung innerhalb einer Infrastruktur. Die Angriffe erforderten weder eine Authentifizierung noch eine Interaktion durch einen Benutzer.
Ein Update des verwendeten CMS oder Shops allein konnte das Problem daher nicht beheben. Entscheidend war die zugrunde liegende PHP-Laufzeitumgebung.
Die beiden Schwachstellen beruhten auf unterschiedlichen Fehlern bei der Verarbeitung von Anfragen und der Verwaltung interner Speicherstrukturen.
Bei der Verarbeitung einer Anfrage kann PHP in einen Zustand geraten, in dem nicht mehr genügend Speicher zur Verfügung steht. Wird die Verarbeitung dadurch unterbrochen, können interne Datenstrukturen unvollständig initialisiert sein. Die anschließende Bereinigungsroutine behandelt diesen Zustand jedoch unter Umständen so, als wären die Strukturen vollständig und gültig aufgebaut worden.
Dadurch können fehlerhafte Speicherzugriffe entstehen, die sich unter bestimmten Voraussetzungen zur Ausführung von Schadcode ausnutzen lassen.
PHP verarbeitet Anfragen häufig innerhalb langlebiger Worker-Prozesse, die nacheinander mehrere Anfragen bearbeiten. Bei dieser Schwachstelle konnten interne Zustände einer Anfrage über deren Ende hinaus bestehen bleiben, obwohl der zugehörige Speicher bereits freigegeben worden war.
Wurde derselbe Worker anschließend für eine weitere Anfrage verwendet, konnte dieser veraltete Zustand vor seiner regulären Initialisierung erneut zum Einsatz kommen. Auch daraus ergab sich unter bestimmten Voraussetzungen ein Angriffspfad zur Ausführung von Schadcode.
Beide Schwachstellen zeigen, wie kritisch Fehler im Umgang mit Speicher, internen Zuständen und der Fehlerbehandlung einer Laufzeitumgebung sein können. Solche Fehler sind besonders problematisch, wenn sie über öffentlich erreichbare Schnittstellen ausgelöst werden können.
Die technischen Hintergründe sind in den offiziellen PHP-Sicherheitsmeldungen dokumentiert:
Eine hohe CVSS-Bewertung ist allein noch kein Beleg dafür, dass ein Angriff tatsächlich stattgefunden hat. Sie beschreibt vielmehr die Schwere und die möglichen Auswirkungen einer Schwachstelle unter den zugrunde gelegten Bedingungen.
Im konkreten Fall kamen jedoch mehrere Risikofaktoren zusammen:
Das BSI stellte in seinem Lagebericht vom 22. Oktober klar, dass ihm zu diesem Zeitpunkt keine erfolgreiche Ausnutzung der Schwachstellen in der Breite bekannt war. Gleichzeitig wies es auf beobachtete Ausnutzungsversuche und das weiterhin hohe Risiko ungepatchter Systeme hin.
Für uns bedeutete das: Wir konnten nicht darauf warten, dass ein erfolgreicher Angriff auf unsere Infrastruktur nachgewiesen wurde. Entscheidend war, das Risiko rechtzeitig zu reduzieren.
Die Herausforderung bestand darin, die Sicherheit der Systeme zu gewährleisten, obwohl zunächst weder die vollständigen technischen Details noch die offiziellen Patches vorlagen.
Wir haben unsere Maßnahmen deshalb an die jeweilige Lage angepasst und in mehreren Schritten umgesetzt.
Am Morgen des 21. Oktober informierten wir unsere Kunden per E-Mail über die beiden Schwachstellen und die vorläufige Risikobewertung.
Da zu diesem Zeitpunkt noch keine offiziellen Sicherheitsupdates verfügbar waren, konnten wir die Schwachstellen nicht unmittelbar durch ein reguläres PHP-Update beheben. Gleichzeitig war die Bedrohung aufgrund der kritischen Bewertung und der unklaren Angriffsmöglichkeiten erheblich.
Wir stellten deshalb eine Anleitung bereit, mit der Kunden ihre Systeme über die ISPConfig-Firewall selbst isolieren konnten. Alternativ war es möglich, Websites vorübergehend zu deaktivieren oder über ISPConfig einen Wartungsmodus zu aktivieren.
Dabei war uns wichtig, den Unterschied zwischen einer vollständigen Isolation und einem gewöhnlichen Wartungsmodus deutlich zu machen.
Ein Wartungsmodus innerhalb einer Webanwendung reicht bei einer Schwachstelle, die bereits während der Verarbeitung einer Anfrage durch PHP ausgelöst werden kann, nicht zwangsläufig aus. Die Anfrage kann die verwundbare Laufzeitumgebung erreichen, bevor der Anwendungscode den Wartungsmodus überhaupt auswertet.
Deshalb empfahlen wir, zusätzlich den Zugriff auf die betroffenen Dienste über die Firewall einzuschränken. Für Kunden, die ihre Systeme nicht selbst isolieren konnten, blieb die Möglichkeit einer vorübergehenden Abschaltung.
Unsere Entscheidung zu diesem Zeitpunkt: Wir wollten unseren Kunden konkrete Handlungsmöglichkeiten geben, ohne eine Schutzwirkung zu versprechen, die technisch noch nicht zuverlässig beurteilt werden konnte.
Im weiteren Verlauf des Tages wurden zusätzliche technische Details öffentlich. Gleichzeitig verdichteten sich die Hinweise auf eine mögliche aktive Ausnutzung.
Damit änderte sich die Ausgangslage: Die Schwachstellen waren nicht mehr nur ein abstraktes Risiko, dessen technische Einzelheiten noch geklärt werden mussten. Vielmehr musste damit gerechnet werden, dass Angreifer die verfügbaren Informationen kurzfristig für konkrete Angriffe nutzen würden.
Wir entschieden uns daher, zwischen 15 und 16 Uhr vorübergehend sämtliche Websites auf unseren Servern sowie die ISPConfig-Oberflächen zu deaktivieren.
Uns ist bewusst, dass eine solche Maßnahme erhebliche Auswirkungen hat. Websites sind für viele Kunden ein geschäftskritischer Bestandteil ihrer Tätigkeit. Eine Abschaltung kann Bestellungen verhindern, Informationsangebote unterbrechen und die Erreichbarkeit eines Unternehmens beeinträchtigen.
Trotzdem haben wir uns in dieser Situation bewusst für die Abschaltung entschieden.
Der Grund war die fehlende Möglichkeit, die Angriffsfläche zu diesem Zeitpunkt abschließend zu bewerten. Wir konnten nicht zuverlässig beurteilen, welche Anfragen die Schwachstellen auslösen würden und ob sich alle relevanten Angriffspfade durch gezielte Filterregeln abdecken ließen.
Eine Web Application Firewall (WAF) kann bekannte Angriffsmuster erkennen und blockieren. Ihre Wirksamkeit hängt jedoch davon ab, ob die relevanten Muster bekannt sind und zuverlässig erkannt werden. Bei einer neu bekannt gewordenen Schwachstelle mit noch unvollständig verstandenen Angriffsmöglichkeiten ist das keine ausreichende Grundlage, um einen vollständigen Schutz zu gewährleisten.
Das BSI wies ebenfalls darauf hin, dass vollständiger Schutz nach damaligem Kenntnisstand nur durch das Einspielen der Patches oder durch die Trennung der betroffenen Systeme vom Internet erreicht werden konnte.
Unsere Entscheidung war deshalb bewusst konservativ: Wir haben eine vorübergehende Einschränkung der Verfügbarkeit in Kauf genommen, um die Integrität der Systeme und die Daten unserer Kunden bestmöglich zu schützen. Mit dieser Entscheidung waren wir nicht allein: Deutschland- und sogar weltweit haben Hostinganbieter Webseiten vom Netz genommen.
Nach der Veröffentlichung der offiziellen Sicherheitsupdates begannen wir mit dem Rollout der korrigierten PHP-Versionen.
Am frühen Abend waren die von den PHP-Entwicklern noch gepflegten Versionszweige PHP 8.2 bis 8.5 auf unseren Shared-Hosting- und Managed-Systemen aktualisiert.
Nach der Installation dieser Patches konnten wir die entsprechenden Systeme wieder freigeben. Für Websites, die noch ältere PHP-Versionen verwendeten, war damit jedoch noch keine abschließende Lösung erreicht.
Diese Systeme waren weiterhin als potenziell verwundbar zu behandeln, solange kein geeigneter Patch installiert war.
Wir aktivierten deshalb für die betroffenen Websites den ISPConfig-Wartungsmodus. Dieser lieferte eine statische HTML-Seite aus, anstatt die reguläre PHP-Anwendung aufzurufen.
Das war ein wichtiger Unterschied zur Verwendung des Wartungsmodus innerhalb eines CMS oder Shops: Durch die statische Auslieferung wurde die PHP-basierte Anwendung für die betreffenden Zugriffe nicht regulär ausgeführt.
Wir hielten die Einschränkung für diese Systeme aufrecht, bis auch für die älteren bereitgestellten PHP-Versionen eine geeignete Lösung umgesetzt werden konnte.
Im weiteren Verlauf des Abends konnten wir auch die älteren PHP-Versionen bis hinunter zu PHP 5.6 patchen.
Damit standen auf unseren Servern aktualisierte Fassungen für sämtliche von uns bereitgestellten PHP-Versionen zur Verfügung. Wir begannen anschließend, die noch aktiven Wartungsmaßnahmen aufzuheben und die Websites sowie die ISPConfig-Oberflächen wieder freizugeben.
Gegen 22 Uhr deutscher Zeit war die Wiederherstellung des regulären Betriebs abgeschlossen.
Am 22. Oktober bestätigten wir unseren Kunden, dass Server und Websites nach dem Einspielen der Patches stabil liefen. Gleichzeitig kündigten wir an, die Lage weiterhin aufmerksam zu beobachten und auf neue Erkenntnisse oder weitere erforderliche Maßnahmen zu reagieren.
Die vorübergehende Abschaltung war die einschneidendste Maßnahme des Tages. Deshalb möchten wir die dahinterstehende Abwägung noch einmal ausdrücklich erläutern.
Bei einer kritischen Sicherheitslücke müssen Betreiber unter Zeitdruck mehrere Faktoren berücksichtigen:
Zum Zeitpunkt unserer Entscheidung waren die technischen Details noch nicht vollständig ausgewertet, die offiziellen Patches noch nicht flächendeckend verfügbar und die Möglichkeiten einer zuverlässigen Filterung nicht abschließend bewertbar.
Eine Fortsetzung des Betriebs unter Einsatz einer WAF oder einzelner Firewall-Regeln hätte die Verfügbarkeit zwar erhalten, zugleich aber ein Restrisiko bestehen lassen, dessen Umfang wir nicht zuverlässig bestimmen konnten.
Eine vollständige Abschaltung war dagegen eine klar definierte Schutzmaßnahme: Die betroffenen Dienste waren vorübergehend nicht mehr über die entsprechenden Zugangswege erreichbar. Damit reduzierten wir die Möglichkeit, die Schwachstellen über diese Dienste auszunutzen.
Die Entscheidung beruhte somit nicht auf der Annahme, dass bereits alle Systeme angegriffen worden seien. Sie beruhte auf der Kombination aus hoher potenzieller Schadenswirkung, unklarer Angriffsfläche und dem erheblichen Zeitdruck bis zur Verfügbarkeit der Patches.
Wir haben die Abschaltung aufgehoben, sobald die notwendigen Sicherheitsupdates installiert waren und die betroffenen Systeme wieder sicher betrieben werden konnten.
Sicherheit und Verfügbarkeit sind beide zentrale Qualitätsmerkmale eines Hostingbetriebs. In einer akuten Sicherheitslage kann es jedoch notwendig sein, die Verfügbarkeit zeitlich begrenzt einzuschränken, um schwerwiegendere Schäden zu verhindern.
Uns ist bewusst, dass die Ereignisse des 21. Oktober für viele Kunden mit erheblichen Einschränkungen verbunden waren. Websites und Verwaltungsoberflächen waren zeitweise nicht erreichbar, und einige Kunden mussten ihre eigenen Schutzmaßnahmen an die veränderte Situation anpassen.
Wir haben versucht, die Auswirkungen durch eine zeitnahe Kommunikation und eine möglichst schnelle Wiederherstellung des Betriebs zu begrenzen.
Kunden auf unseren Managed-Systemen mussten die serverseitigen PHP-Updates nicht selbst durchführen. Die Aktualisierung und die anschließende Freigabe der Systeme erfolgten durch uns.
Firewall-Regeln, Wartungsmodi und andere Schutzmaßnahmen, die Kunden selbst eingerichtet hatten, haben wir bei der Wiederherstellung nicht automatisch verändert.
Das war eine bewusste Entscheidung: Solche Regeln können Teil individueller Sicherheitskonzepte sein. Wir wollten sie nicht ohne Zustimmung unserer Kunden entfernen und dadurch möglicherweise andere Schutzmechanismen außer Kraft setzen.
Kunden, die sich durch ihre eigenen Maßnahmen aus ihrem System ausgesperrt hatten, konnten sich an uns wenden. Für diese Fälle boten wir Unterstützung über ein kostenfreies Notfallticket an.
Wir informierten unsere Kunden per E-Mail und veröffentlichten fortlaufend Aktualisierungen auf unserer Statusseite.
Dabei verfolgten wir zwei Ziele: Zum einen sollten Kunden nachvollziehen können, weshalb Dienste vorübergehend nicht erreichbar waren. Zum anderen wollten wir transparent machen, welche Maßnahmen bereits abgeschlossen waren und welche Einschränkungen noch bestanden.
Während die technischen Teams an der Absicherung und Wiederherstellung arbeiteten, baten wir darum, von individuellen Anfragen zum gleichen Sachverhalt abzusehen. So konnten sich unsere Techniker möglichst vollständig auf die Behebung des Problems konzentrieren.
Wir wissen, dass eine solche Bitte in einer Situation, in der die eigene Website nicht erreichbar ist, Geduld erfordert. Gleichzeitig ist es gerade bei einem zeitkritischen Sicherheitsvorfall wichtig, die verfügbaren technischen Kapazitäten auf die unmittelbar erforderlichen Maßnahmen zu konzentrieren.
Nach unserem derzeitigen Kenntnisstand liegen uns keine Hinweise auf erfolgreiche Angriffe oder kompromittierte Kundensysteme im Zusammenhang mit diesen beiden Schwachstellen vor.
Diese Aussage ist bewusst eng gefasst. Sie bedeutet, dass uns bislang keine entsprechenden Hinweise vorliegen. Sie ist kein allgemeiner Nachweis dafür, dass eine Kompromittierung unter allen Umständen ausgeschlossen werden kann.
Das BSI stellte in seinem Lagebericht vom 22. Oktober ebenfalls fest, dass ihm zu diesem Zeitpunkt keine erfolgreiche Ausnutzung in der Breite bekannt war. Gleichzeitig wies es auf Berichte über Ausnutzungsversuche hin und betonte, dass erfolgreiche Angriffe nicht ausgeschlossen werden können.
Darüber hinaus stehen bislang keine konkreten Indicators of Compromise (IoCs) zur Verfügung, mit denen sich sämtliche möglichen Ausnutzungen der Schwachstellen zuverlässig erkennen lassen.
Deshalb ist es grundsätzlich sinnvoll, Webserver und Anwendungen auch nach einem Sicherheitsupdate auf Auffälligkeiten zu prüfen. Dazu gehören beispielsweise:
Ein Sicherheitsupdate behebt die bekannte Schwachstelle, entfernt aber nicht automatisch Schadcode, der zuvor auf einem System platziert worden sein könnte.
Wir beobachten die Lage deshalb weiterhin und behalten neue technische Erkenntnisse im Blick.
Im Zuge des Vorfalls haben wir auch ältere PHP-Versionen bis hinunter zu PHP 5.6 mit entsprechenden Patches versorgt.
Das war notwendig, um die konkrete Gefährdung durch CVE-2026-109618 und CVE-2026-109619 auf den von uns bereitgestellten Versionszweigen zu beheben.
Es ist jedoch wichtig, zwischen einem Patch für eine konkrete Schwachstelle und einer langfristig unterstützten Softwareversion zu unterscheiden.
PHP-Versionen unterhalb von 8.2 erhalten vom PHP-Projekt keine reguläre Sicherheitswartung mehr. Auch für PHP 8.2 ist die Unterstützung zeitlich begrenzt und endet nach dem Stand vom Oktober 2026 am 31. Dezember 2026.
Ein gezielter Patch kann eine bekannte Sicherheitslücke schließen. Er bedeutet aber nicht, dass für eine ältere Version künftig auch weitere entdeckte Schwachstellen beheben werden oder sie wieder den regulären Supportstatus erhält.
Wir empfehlen deshalb, Websites und Anwendungen mittelfristig auf eine von den PHP-Entwicklern noch unterstützte Version umzustellen.
Bei diesem Schritt sollten Betreiber nicht nur die PHP-Version auf dem Server betrachten, sondern auch prüfen, ob die eingesetzten CMS, Erweiterungen, Themes und individuellen Anwendungen mit der Zielversion kompatibel sind.
Ein planvoller Versionswechsel reduziert das Risiko, bei der nächsten kritischen Sicherheitsmeldung erneut auf einen nicht regulär unterstützten Softwarezweig angewiesen zu sein.
Die PHP2Shell-Schwachstellen waren aufgrund ihrer technischen Eigenschaften, der weiten Verbreitung von PHP und der kurzen Reaktionszeit eine außergewöhnliche Herausforderung für Betreiber von Websites und Servern.
Wir haben am Morgen des 21. Oktober informiert, unseren Kunden Möglichkeiten zur vorübergehenden Isolation bereitgestellt, angesichts der veränderten Bedrohungslage sämtliche Websites und ISPConfig-Oberflächen vorübergehend abgeschaltet und die Systeme nach der Verfügbarkeit der Sicherheitsupdates schrittweise wieder freigegeben.
Noch am selben Abend konnten wir die Patches für sämtliche von uns bereitgestellten PHP-Versionen bis hinunter zu PHP 5.6 einspielen und den regulären Betrieb wiederherstellen. Nach unserem derzeitigen Kenntnisstand liegen uns keine Hinweise auf erfolgreiche Angriffe oder kompromittierte Kundensysteme vor.
Die Abschaltung war ein einschneidender Schritt. Wir haben ihn dennoch bewusst gewählt, weil die Risiken einer möglichen Kompromittierung unter den damaligen Bedingungen schwerer wogen als die zeitlich begrenzte Einschränkung der Verfügbarkeit.
Unser Dank gilt unseren Kunden für ihre Geduld, ihre Unterstützung und die konstruktiven Rückmeldungen während des Vorfalls.
Wir werden die weitere Entwicklung aufmerksam verfolgen und unsere Sicherheitsmaßnahmen bei Bedarf anpassen. Gleichzeitig empfehlen wir allen Kunden, ihre Websites mittelfristig auf unterstützte PHP-Versionen umzustellen und die Aktualität ihrer Anwendungen und technischen Abhängigkeiten regelmäßig zu überprüfen.
Unser Anspruch bleibt, Sicherheitsrisiken frühzeitig zu erkennen, angemessen darauf zu reagieren und unsere Entscheidungen auch dann transparent zu erklären, wenn sie mit Einschränkungen für unsere Kunden verbunden sind.
Zum 1. Februar 2027 schalten wir Server Side Includes (SSI) auf allen Hostingangeboten ab. Erfahren Sie, warum wir die veraltete Technik aus unserer Hosting-Infrastruktur entfernen, welche Aspekte dabei eine Rolle spielen und ob Sie für Ihre Website aktiv werden müssen.
Testen Sie uns 14 Tage kostenlos Jetzt testen
