Als bevorzugte Quelle bei Google hinzufügen
Am 21. Oktober 2026 griffen Angreifer bereits Websites mit Anfragen an, die darauf abzielten, zwei kritische PHP-Sicherheitslücken auszunutzen, die als „PHP2Shell“ bekannt sind. Die offiziellen Sicherheitspatches waren noch nicht verfügbar, aber unsere Entwickler- und Sicherheitsteams arbeiteten bereits daran, die bei Kinsta gehosteten Websites zu schützen.
Die Reaktion umfasste mehrere Maßnahmen. Unser Team aktivierte Notfall-Firewall-Regeln bei Cloudflare, passte die PHP-Konfigurationen an und bereitete sich darauf vor, die Patches auf Hunderttausende von Containern zu installieren, sobald sie verfügbar waren. Gleichzeitig beantwortete unser Support-Team eine Flut von Fragen von Kunden, die sich Sorgen um ihre Websites machten.
Bis zum 23. Oktober hatten unsere Cloudflare-Schutzmaßnahmen mehr als 550.000 Anfragen blockiert, die auf die Sicherheitslücken abzielten. Außerdem hatten wir die notwendigen PHP-Sicherheitsupdates auf unserer gesamten Hosting-Plattform bereitgestellt und keine Anzeichen für erfolgreiche Angriffe gefunden.
So verlief die Reaktion – von den ersten Anzeichen der Ausnutzung über die Bereitstellung der Patches bis hin zu den anschließenden Maßnahmen.
Vorbereitungen auf PHP2Shell, bevor die Patches verfügbar waren
Am 20. Oktober kündigte das PHP-Sicherheitsteam ein bevorstehendes kritisches Sicherheitsupdate an, das für den folgenden Tag geplant war. In der Ankündigung wurde vor zwei Schwachstellen mit einem CVSS 4.0-Schweregrad von 9,2 gewarnt und PHP-Nutzer wurden aufgefordert, sich darauf vorzubereiten, ihre Installationen zu aktualisieren, sobald die Patches verfügbar sind.
Die Sicherheitslücken, die später als CVE-2026-109618 und CVE-2026-109619 identifiziert wurden, betreffen die interne Speicherverwaltung von PHP und könnten es Angreifern unter bestimmten Umständen ermöglichen, Code aus der Ferne ohne Authentifizierung auszuführen.
Die Ankündigung war besonders für WordPress-Websites von Bedeutung, da PHP die Anwendung selbst ausführt. Ein Update eines WordPress-Plugins oder -Themes konnte diese Sicherheitslücken nicht beheben. Die zugrunde liegende PHP-Laufzeitumgebung benötigte Sicherheitspatches.
Für Hosting-Anbieter wie Kinsta bestand die erste Herausforderung darin, die Websites zu schützen, bevor die offiziellen Patches verfügbar waren. Unser Team begann mit den Vorbereitungen für die Veröffentlichung, doch es gab bereits erste Ausnutzungsversuche.
Laut Laszlo Farkas, Director of Engineering bei Kinsta, beobachtete unser Team bereits in den frühen Morgenstunden des 21. Oktober Anfragen, die auf die Sicherheitslücken abzielten. Die Entwickler überprüften die betroffenen Websites manuell und überwachten die Aktivitäten weiterhin auf Anzeichen eines erfolgreichen Angriffs.
Zu diesem Zeitpunkt hatten wir bereits Maßnahmen ergriffen, um die Websites auf unserer Plattform zu schützen.
So haben wir die Notfall-WAF-Regeln von Cloudflare aktiviert
Jede auf Kinsta gehostete Website wird von Cloudflare geschützt, einschließlich der Produktions- und Staging-Umgebungen. So kann unser Entwicklerteam Firewall-Schutzmaßnahmen plattformweit anwenden, ohne dass Kunden Regeln für einzelne Websites konfigurieren müssen.
Noch vor der öffentlichen Bekanntgabe von PHP2Shell führte Cloudflare Notfallregeln für die Web Application Firewall (WAF) ein, um Ausnutzungsversuche zu erkennen. Unser Entwicklerteam verfolgte das WAF-Changelog von Cloudflare genau, sobald neue Regeln verfügbar wurden, prüfte diese und stellte die Aktion so schnell wie möglich auf „Blockieren“ ein.
Da jede Kinsta-Website bereits hinter Cloudflare läuft, konnten wir diese Schutzmaßnahmen plattformweit anwenden – sowohl in Produktions- als auch in Staging-Umgebungen –, ohne dass Kunden etwas unternehmen mussten.
Dieser plattformweite Schutz war wichtig, da PHP2Shell keine typische Schwachstelle auf Anwendungsebene war. Die Angriffe zielten direkt auf PHP selbst ab, sodass WordPress-Sicherheitsupdates oder Schutzmaßnahmen auf Plugin-Ebene das zugrunde liegende Problem nicht hätten beheben können.
Die WAF-Regeln ermöglichten es uns, bekannte Ausnutzungsversuche zu blockieren, während wir PHP-Patches vorbereiteten. Cloudflare aktualisierte seine Schutzmaßnahmen kontinuierlich, während die Angreifer ihre Techniken änderten. In seinem technischen Bericht zu PHP2Shell wird beschrieben, wie Angreifer ihre Payloads modifizierten, um bestehende Erkennungsmechanismen zu umgehen.
Cloudflare führte außerdem eine vollständige Transaktionserkennung ein, die Signale sowohl aus der HTTP-Anfrage als auch aus der Antwort des Servers analysiert. Dies liefert zusätzliche Informationen zur Identifizierung verdächtiger Anfragen und kann verhindern, dass eine passende Antwort den Anfragenden erreicht.
Unsere Entwickler konnten beobachten, wie sich die Angriffsmuster änderten, sobald neue Regeln verfügbar wurden.
Bis zum 23. Oktober hatten die Cloudflare-Schutzmaßnahmen für Kinsta-Websites mehr als 550.000 Anfragen blockiert, die auf PHP2Shell abzielten.
Diese Zahl bezieht sich auf blockierte Anfragen im Zusammenhang mit den Sicherheitslücken, nicht auf erfolgreiche Angriffe oder einzelne Angreifer. Sie spiegelt den verdächtigen Datentraffic wider, den unsere Firewall-Schutzmaßnahmen abgefangen haben, während das Team an der Bereitstellung der PHP-Patches arbeitete.
Einführung vorübergehender PHP-Konfigurationsschutzmaßnahmen
Wir haben uns nicht allein auf Cloudflare verlassen. Während wir auf gepatchte PHP-Pakete warteten, hat unser Entwicklerteam außerdem PHP-Konfigurationsänderungen in unseren Hosting-Umgebungen eingeführt, um die Anfälligkeit gegenüber bekannten Ausnutzungswegen zu verringern.
Eine dieser Änderungen bestand darin, die PHP-Funktion zur Anzeige des Upload-Fortschritts in der Sitzung mithilfe der Einstellung session.upload_progress.enabled zu deaktivieren.
Der Sicherheitshinweis von PHP identifiziert diese Einstellung als Abhilfemaßnahme für bestimmte Angriffswege. Das Deaktivieren hilft dabei, Angriffe zu blockieren, die auf der Verarbeitung des Session-Upload-Fortschritts durch PHP beruhen, auch wenn dadurch nicht alle möglichen Ausnutzungsmöglichkeiten der Schwachstellen abgedeckt werden.
Die Firewall-Regeln und Konfigurationsänderungen boten zusätzlichen Schutz, solange noch keine Patches verfügbar waren oder diese noch bereitgestellt wurden. Die Aktualisierung der PHP-Laufzeitumgebung blieb jedoch weiterhin notwendig.
Am 23. Oktober veröffentlichte das PHP-Team einen weiteren Hinweis, in dem empfohlen wurde, den Upload-Fortschritt bei Sessions bis zur Veröffentlichung eines nachfolgenden Bugfix-Releases deaktiviert zu lassen. Dies bekräftigte die Vorsichtsmaßnahme, die unser Entwicklerteam bereits ergriffen hatte.
Unsere Cloudflare-Regeln und lokalen Konfigurationsschutzmaßnahmen blieben während der gesamten Patch-Einführung bestehen, unabhängig davon, ob eine einzelne Umgebung ihr aktualisiertes PHP-Paket bereits erhalten hatte.
Bereitstellung von PHP-Patches in Hunderttausenden von Containern
Als das PHP-Entwicklungsteam am 21. Oktober die Sicherheitsupdates veröffentlichte, bestand unsere nächste Herausforderung darin, diese Korrekturen in der gesamten Hosting-Infrastruktur bereitzustellen.
Die offiziellen Releases umfassten PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Kinsta unterstützt jedoch auch ältere PHP-Versionen, für die Sicherheitskorrekturen von externen Betreibern erforderlich waren.
Wir haben mit Freexian, unserem PHP-Paketanbieter, zusammengearbeitet, um gepatchte Pakete für die auf unserer Plattform laufenden PHP-Versionen zu erhalten, einschließlich älterer Versionen mit langfristigem Support.
Die Pakete wurden nach und nach verfügbar, nicht alle auf einmal. Sobald ein neuer Build in unserem Paket-Mirror eintraf, hat unser Entwicklerteam ihn geprüft und mit der Bereitstellung begonnen, ohne darauf zu warten, dass jeder PHP-Zweig fertig war.
So verlief die Einführung:
| Datum und Uhrzeit (UTC) | Was geschah |
| 21. Oktober, ca. 14:00–17:45 | PHP veröffentlichte die Sicherheitspatches. PHP 8.5.12 war um 14:24 Uhr in unserem Paket-Mirror verfügbar, und die Bereitstellung begann um 15:54 Uhr. Bis 17:45 Uhr waren Zehntausende von Containern aktualisiert worden. |
| 21. Oktober, 18:50–19:04 | PHP 8.3.36 wurde verfügbar, und die Bereitstellung begann parallel zu PHP 8.5. |
| 21. Oktober, 21:17–22:28 | Gepatchte Pakete für PHP 7.4, 8.0 und 8.1 wurden verfügbar, und weitere Bereitstellungen begannen um 22:28 Uhr. |
| 21.–22. Oktober, 23:25–01:37 | Die Pakete für PHP 8.2 und 8.4 trafen um 23:25 Uhr ein, die Bereitstellung begann am 22. Oktober um 01:37 Uhr. |
| 22. Oktober, 04:31 | Nur noch 1.888 Container, etwa 0,5 % der Gesamtzahl, mussten aktualisiert werden und erforderten zusätzliche Aufmerksamkeit. |
| 22. Oktober, 08:26 | Wir haben eine 100-prozentige Schutzabdeckung bestätigt und den Vorfall als gelöst markiert. |
Die Fähigkeit, Änderungen in dieser Größenordnung bereitzustellen, war einer der wichtigsten Aspekte der Reaktion.
Farkas hob hervor, wie schnell das Team Änderungen in der gesamten Infrastruktur bereitstellen konnte:
„Darauf bin ich am meisten stolz. Sobald eine Änderung validiert ist und wir wissen, dass sie keine Probleme verursacht, können wir sie innerhalb weniger Stunden in der gesamten Infrastruktur ausrollen.“
Dank dieser Fähigkeit konnte unser Team innerhalb weniger Stunden gepatchte PHP-Pakete in Hunderttausenden von Containern bereitstellen.
Außerdem mussten wir PHP-Updates nicht mit einzelnen Kunden abstimmen. Kinsta verwaltet PHP auf Plattformebene – sobald die Entwickler ein aktualisiertes Paket validiert hatten, konnten wir es in allen betroffenen Umgebungen bereitstellen, ohne die Website-Betreiber bitten zu müssen, die Updates selbst zu installieren.
Warum ältere PHP-Versionen zusätzliche Korrekturen benötigten
Bei der Einführung musste auch der Unterschied zwischen den offiziell unterstützten PHP-Zweigen und älteren Versionen, die von Drittanbietern gepflegt werden, berücksichtigt werden.
Das PHP-Projekt veröffentlichte Sicherheitsupdates für PHP 8.2 bis 8.5. Versionen wie PHP 7.4, 8.0 und 8.1 erhielten keine regelmäßigen Sicherheitsupdates mehr direkt vom PHP-Projekt, obwohl Anbieter mit langfristigem Support (LTS) zurückportierte Korrekturen bereitstellen konnten.
Durch Backporting können Betreuer Sicherheitskorrekturen auf einen älteren Softwarezweig anwenden, ohne dass Nutzer auf eine neuere PHP-Version upgraden müssen.
Das bedeutete, dass wir Sicherheitsupdates für diese älteren PHP-Umgebungen bereitstellen konnten, sobald Freexian gepatchte Pakete veröffentlichte.
Das erklärt auch, warum eine PHP-Versionsnummer allein nicht immer Aufschluss darüber gibt, ob ein bestimmter Sicherheitspatch bereits angewendet wurde. Von Anbietern gepflegte Pakete können gepatchten Code enthalten, ohne dieselbe Versionsnummer wie die offizielle Upstream-Version von PHP anzuzeigen.
Während der gesamten Einführungsphase haben wir weiterhin Updates bereitgestellt und dabei die zusätzlichen Schutzmaßnahmen durch Firewalls und Konfigurationen aufrechterhalten.
Angriffe überwachen und auf Anzeichen einer Kompromittierung prüfen
Das Bereitstellen von Patches war nur ein Teil der Reaktion. Unser Team musste außerdem feststellen, ob beobachtete Ausnutzungsversuche erfolgreich waren.
Als wir in den frühen Morgenstunden des 21. Oktober erstmals Aktivitäten bemerkten, die auf von Kinsta gehostete Websites abzielten, untersuchten unsere Ingenieure die betroffenen Websites manuell.
Sie überwachten während des gesamten Vorfalls weiterhin verdächtigen Datentraffic und führten Stichproben in den Hosting-Umgebungen durch, um Anzeichen dafür zu finden, dass Angreifer die Schwachstellen erfolgreich ausgenutzt hatten.
Die Sicherheitsereignisse von Cloudflare halfen uns zu verstehen, was ins Visier genommen wurde und wie sich die Angriffsmuster änderten, während wir neue Regeln veröffentlichten. Die Anzahl der blockierten Anfragen allein konnte uns jedoch nicht sagen, ob Angriffe erfolgreich waren.
Deshalb waren die manuellen Überprüfungen so wichtig. Unser Team stand außerdem in engem Kontakt mit Patchstack, unserem Partner für Schwachstellenschutz, und tauschte Informationen über die Bedrohungen und Angriffsmuster aus, die beide Teams beobachtet hatten. Wir nahmen auch an Diskussionen mit anderen Hosting-Anbietern teil, um Informationen und bewährte Vorgehensweisen auszutauschen, während die breitere PHP-Community reagierte.
Diese Bemühungen ergänzten unsere Zusammenarbeit mit Cloudflare und Freexian. Cloudflare stellte Schutzmaßnahmen gegen Ausnutzungsversuche bereit, Freexian lieferte die gepatchten PHP-Pakete, und die Koordination mit unseren Sicherheitspartnern half unseren Ingenieuren zu verstehen, wie sich die Bedrohung entwickelte.
Während des gesamten Vorfalls fanden wir keine Hinweise auf erfolgreiche Sicherheitsverletzungen im Zusammenhang mit PHP2Shell.
Diese Erkenntnis basiert auf der Überwachung und den Untersuchungen, die während der Reaktion durchgeführt wurden. Das bedeutet nicht, dass es keine Angriffe gab, wie die Firewall-Daten zeigen. Es bedeutet, dass unsere Überprüfungen keine Anzeichen für eine erfolgreiche Kompromittierung ergeben haben.
Behebung des Vorfalls und weitere Überprüfung
Am 22. Oktober um 08:26 Uhr UTC haben wir den PHP-Sicherheitsvorfall auf unserer öffentlichen Statusseite als behoben markiert.
Zu diesem Zeitpunkt hatten wir bereits Sicherheitsupdates plattformweit ausgerollt, und alle Websites waren durch eine Kombination aus Patches und Abhilfemaßnahmen geschützt.
Die Behebung bedeutete nicht, dass wir mit der Überprüfung aufgehört haben. Unser Team hat auch nach dem Abschluss des öffentlichen Vorfalls weiterhin die Umgebungen überprüft und die Schutzmaßnahmen überwacht.
Das war bei einer Einführung wichtig, die mehrere PHP-Zweige und Hunderttausende von Containern umfasste. Um 04:31 UTC benötigten noch etwa 0,5 % der Container zusätzliche Aufmerksamkeit. Unsere Ingenieure arbeiteten sich weiter durch diese verbleibenden Umgebungen und überprüften die Ergebnisse, anstatt die Verfügbarkeit eines gepatchten Pakets als Beweis dafür zu betrachten, dass jede Installation aktualisiert worden war.
Die Cloudflare-Regeln und die Schutzmaßnahmen für die PHP-Konfiguration blieben während dieser Überprüfungsarbeiten ebenfalls bestehen.
Für die Kunden erforderten die PHP-Sicherheitsupdates keine manuellen Patches oder Versionswechsel.
Reaktion auf Kunden, die zusätzliche Vorsichtsmaßnahmen ergriffen
Die Reaktion auf PHP2Shell ging weit über Hosting-Anbieter hinaus. Als sich die Nachricht von den Sicherheitslücken verbreitete, begannen Regierungsbehörden und andere Organisationen weltweit, Websites vorübergehend offline zu nehmen, während sie Sicherheitsupdates vorbereiteten.
In den Niederlanden nahm das Nationale Cybersicherheitszentrum seine eigene Website vorsorglich offline. Auch Regierungswebsites in Deutschland, Frankreich, Belgien und Finnland wurden vorübergehend gesperrt. In Japan gab Premierministerin Sanae Takaichi auf X eine dringende Warnung heraus und forderte Website-Betreiber auf, die Patches so schnell wie möglich zu installieren oder den Betrieb vorübergehend einzustellen, falls sie nicht sofort aktualisieren könnten.
Bei Kinsta konnten wir ähnliche Bedenken bei unseren Kunden beobachten. Unser Support-Team verzeichnete einen deutlichen Anstieg an Anfragen zu PHP2Shell, und einige Kunden begannen, zusätzliche Vorsichtsmaßnahmen zum Schutz ihrer Websites zu ergreifen.
Dazu gehörten die Nutzung der Funktion zur Aussetzung der Umgebung in MyKinsta, um Websites offline zu nehmen, die Aktivierung von websiteweiten Sicherheitsabfragen über den Bot-Schutz oder die Bitte an den Support, eingehenden Datentraffic auf Serverebene zu blockieren. Während des Vorfalls haben Kunden proaktiv etwa 3.000 Websites ausgesetzt.
Angesichts der Schwere der Sicherheitslücken und der anderswo getroffenen Vorsichtsmaßnahmen waren diese Entscheidungen nachvollziehbar. Die Entwicklungsabteilung empfahl den Kunden jedoch nicht, ihre bei Kinsta gehosteten Websites offline zu nehmen. Wir hatten bereits die Notfall-WAF-Regeln von Cloudflare auf unserer gesamten Hosting-Plattform aktiviert, sodass Websites, die online blieben, weiterhin diesen Schutz erhielten, ohne für Besucher nicht erreichbar zu sein.
Unser Support-Team begann, Kunden von unnötigen Sperrungen abzuraten, während die Entwickler weiterhin die PHP-Patches bereitstellten.
Nachdem wir die Sicherheitsupdates ausgerollt hatten, überprüften wir die während des Vorfalls vorgenommenen Sperrmaßnahmen, um Websites zu identifizieren, die Kunden speziell wegen PHP2Shell offline genommen hatten.
Unser Team reaktivierte dann diese Umgebungen, während Websites, die aus anderen Gründen gesperrt waren, unberührt blieben. Dazu mussten wir vorsorgliche Sperrungen von anderen absichtlichen Sperrungen unterscheiden, anstatt einfach jede Umgebung wiederherzustellen, die offline genommen worden war.
Neben der Abwehr von Angriffen und der Bereitstellung von Patches mussten unsere Teams den Kunden auch dabei helfen, die während des Vorfalls getroffenen Vorsichtsmaßnahmen rückgängig zu machen.
Was die Reaktion für Kinsta-Kunden bedeutete
PHP2Shell erforderte die Zusammenarbeit zwischen den Bereichen Engineering, Support und mehreren externen Sicherheits- und Infrastrukturpartnern. Die Plattform kümmerte sich jedoch selbst um die Installation der Patches.
Die Kunden mussten weder die Verfügbarkeit der einzelnen PHP-Versionen im Auge behalten, noch herausfinden, welches gepatchte Paket ihre Website benötigte, noch die Updates selbst installieren.
Farkas erklärte, was die Reaktion letztendlich für die Kinsta-Kunden bedeutete:
„Für mich ist die wichtigste Botschaft, dass sich die Kunden über nichts davon Gedanken machen mussten: was, wann oder wie sie aktualisieren sollten. Sie waren auf unserer Plattform einfach geschützt.“
Die Reaktion der Kunden während des Vorfalls zeigte auch, warum es wichtig war, über diese Schutzmaßnahmen zu informieren. Einige Kunden nahmen ihre Websites vom Netz, obwohl die Notfall-WAF-Regeln bereits aktiv waren, und unsere Teams arbeiteten anschließend daran, die aufgrund der Sicherheitslücken gesperrten Umgebungen wiederherzustellen.
Unterdessen führte unser Entwicklerteam die PHP-Sicherheitsupdates auf Hunderttausenden von Containern durch, ohne dass die Kunden sich um die Änderungen kümmern mussten.
Eine Übersicht über die Sicherheitsupdates und die Behebung des Vorfalls findest du in unserem PHP-Sicherheitsvorfallbericht.
Hinweise dazu, was die Sicherheitslücken für deine Website bedeuten, findest du in unserem Begleitartikel „PHP2Shell: Wie Kinsta WordPress-Websites geschützt hat“.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
