PHP2Shell-Rollout patchte umfangreiche Hosting-Infrastruktur
PHP2Shell-Exploit-Versuche erreichten bereits am 21. Oktober 2026 Websites, während Hosting-Techniker auf Fixes für zwei kritische PHP-Sicherheitslücken warteten. Kinsta gibt an, mit Cloudflare-Filterung, vorübergehenden Änderungen an der PHP-Konfiguration und einem plattformweiten Patch-Rollout reagiert zu haben, der Hunderttausende container abdeckte. Bis zum 23. Oktober hatten diese Filter mehr als 550.000 zugehörige Anfragen blockiert, während die Untersuchungen des Hosters keine Hinweise darauf fanden, dass ein Versuch erfolgreich gewesen war.
Das PHP-Sicherheitsteam kündigte am 20. Oktober vorab an, dass am folgenden Tag ein kritisches Release erscheinen werde. Die Sicherheitslücken wurden anschließend als CVE-2026-109618 und CVE-2026-109619 identifiziert. Beide betreffen den internen Umgang von PHP mit Speicher und könnten unter bestimmten Bedingungen remote code execution ermöglichen, was bedeutet, dass ein nicht authentifizierter Angreifer den Server dazu bringen könnte, Code auszuführen. Ihr CVSS-4.0-Score betrug 9,2. CVSS, kurz für Common Vulnerability Scoring System, ist eine Standardskala zur Angabe des Schweregrads einer Sicherheitslücke.
Für WordPress-Betreiber war entscheidend, wo sich die Sicherheitslücken befanden. PHP ist die runtime, also die zugrunde liegende Software, die WordPress ausführt. Daher konnte weder die Aktualisierung eines Plugins oder Themes noch die von WordPress selbst den anfälligen PHP-Code korrigieren. Die runtime musste von der jeweils dafür zuständigen Stelle gepatcht werden. Kinsta berichtet, dass seine Techniker in den frühen Morgenstunden des 21. Oktober erstmals auf die Sicherheitslücken abzielende Anfragen bemerkten und die betroffenen Websites manuell auf Hinweise auf eine Kompromittierung untersuchten.
Jede Produktionsumgebung und jedes staging environment auf der Plattform von Kinsta war bereits durch Cloudflare geschützt. Ein staging environment ist eine private Kopie, die zum Testen von Änderungen an einer Website verwendet wird. Cloudflare führte vor der öffentlichen Bekanntgabe von PHP2Shell Notfallregeln für die Web Application Firewall ein. Eine WAF ist ein Filter, der Web-Traffic untersucht und Anfragen ablehnen kann, die bekannten Angriffstechniken entsprechen. Kinsta gibt an, dass seine Techniker jede neue Regel im Changelog von Cloudflare überprüften und ihre Aktion plattformweit auf Block setzten, ohne dass Kunden einzelne Websites konfigurieren mussten.
Diese Filterung bot vorübergehenden Schutz, während gepatchte PHP-Pakete vorbereitet wurden. Cloudflare passte seine Erkennungsmechanismen fortlaufend an, als Angreifer ihre Payloads änderten, um bestehende Regeln zu umgehen. Außerdem führte das Unternehmen full transaction detection ein. Dabei werden sowohl Informationen aus der eingehenden HTTP-Anfrage als auch aus der Serverantwort berücksichtigt, und eine passende Antwort kann daran gehindert werden, den Anfragenden zu erreichen. Bis zum 23. Oktober hatten die Schutzmaßnahmen für Kinsta-Websites mehr als 550.000 Anfragen mit Bezug zu PHP2Shell abgewiesen. Diese Zahl steht für blockierte Anfragen, nicht für einzelne Angreifer, erfolgreiche Kompromittierungen oder zwangsläufig 550.000 separate Angriffskampagnen.
Kinsta deaktivierte außerdem die PHP-Funktion session upload progress über die Einstellung session.upload_progress.enabled. Der Sicherheitshinweis von PHP nannte diese Änderung als Mitigation für einige Exploit-Pfade, obwohl sie nicht jeden möglichen Weg zu den Sicherheitslücken abdeckte. Am 23. Oktober empfahl das PHP-Team zusätzlich, die Funktion bis zu einem späteren Bugfix-Release deaktiviert zu lassen. Kinsta behielt diese Konfigurationsänderung und die Cloudflare-Regeln während des gesamten Patch-Deployments und der Überprüfung bei.
Offizielle Fixes erschienen am 21. Oktober als PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Der Hoster benötigte außerdem Pakete für PHP 7.4, 8.0 und 8.1, also branches, die nicht mehr routinemäßig direkte Sicherheitsupdates vom PHP-Projekt erhielten. Sein Paketanbieter Freexian stellte durch backporting Fixes für diese älteren Long-Term-Support-branches bereit. Dabei wird eine Sicherheitskorrektur auf ältere Software angewendet, ohne ein sofortiges Upgrade auf einen neueren branch zu erzwingen. Das bedeutet zugleich, dass sich allein anhand einer PHP-Versionsnummer nicht immer nachweisen lässt, ob eine vom Anbieter gepflegte Installation einen bestimmten Fix enthält.
Die Pakete trafen nach und nach ein. PHP 8.5.12 wurde am 21. Oktober um 14:24 UTC in den Mirror von Kinsta aufgenommen, das Deployment begann um 15:54 Uhr, und bis 17:45 Uhr waren Zehntausende container aktualisiert. PHP 8.3.36 wurde um 18:50 Uhr verfügbar; sein Rollout begann zusammen mit PHP 8.5 spätestens um 19:04 Uhr. Gepatchte Pakete für PHP 7.4, 8.0 und 8.1 trafen zwischen 21:17 und 22:28 Uhr ein, wobei die Deployments um 22:28 Uhr begannen. Pakete für PHP 8.2 und 8.4 erschienen um 23:25 Uhr, gefolgt vom Deployment am 22. Oktober um 01:37 Uhr. Ein container ist eine isolierte Softwareumgebung, in der eine Website und die zugehörigen Dienste ausgeführt werden.
Am 22. Oktober um 04:31 UTC benötigten noch 1.888 container, rund 0,5 % der Gesamtzahl, zusätzliche Aufmerksamkeit. Kinsta zufolge arbeiteten die Techniker diese Umgebungen einzeln ab, statt die Verfügbarkeit der Pakete als Nachweis für deren Installation zu betrachten. Um 08:26 Uhr meldete das Unternehmen eine Schutzabdeckung von 100 % und erklärte den öffentlich gemeldeten Vorfall für behoben. Anschließend überprüfte das Unternehmen die Umgebungen weiter, während die Mitigations durch seine firewall und die PHP-Konfiguration aktiv blieben.
Aus der Gesamtzahl blockierter Anfragen ließ sich nicht ableiten, ob frühere Versuche erfolgreich gewesen waren. Daher setzten die Techniker manuelle Prüfungen und die Überwachung des Traffics fort. Kinsta gibt an, Bedrohungsinformationen mit Patchstack, seinem Partner für Vulnerability Protection, ausgetauscht und Beobachtungen sowie Vorgehensweisen mit anderen Hosting-Anbietern besprochen zu haben. Cloudflare stellte die Angriffsfilterung bereit, während Freexian die gepatchten Pakete lieferte. Laut Kinsta fanden diese Untersuchungen keine Hinweise auf erfolgreiche Sicherheitsverletzungen im Zusammenhang mit PHP2Shell. Diese bewusst eng gefasste Feststellung bedeutet nicht, dass es keine Angriffe gab.
Die Besorgnis führte außerdem zu vorsorglichen Abschaltungen. Das niederländische National Cyber Security Centre nahm seine Website vorübergehend offline, während Regierungswebsites in Deutschland, Frankreich, Belgien und Finnland ausgesetzt wurden. Japans Premierminister forderte Betreiber auf, schnell zu patchen oder Dienste vorübergehend einzustellen, falls ein Update nicht möglich sei. Kinsta-Kunden setzten vorsorglich etwa 3.000 Websites aus, während andere Challenges für die gesamte Website aktivierten oder Traffic-Sperren auf Serverebene anforderten. Kinsta empfahl nicht, gehostete Websites offline zu nehmen, da seine Notfallfilterung bereits aktiv war. Nach dem Patchen identifizierte und reaktivierte das Unternehmen Umgebungen, die speziell wegen PHP2Shell ausgesetzt worden waren, während nicht damit zusammenhängende Sperrungen unverändert blieben.
Der Vorfall zeigt, warum Websitebetreiber klären sollten, wer ihre PHP-runtime kontrolliert, wie schnell diese Stelle einen Notfall-Fix bereitstellen kann und welche vorübergehenden Schutzmaßnahmen verfügbar sind, bevor Patches eintreffen. Managed Platforms können Updates der runtime zentral durchführen, doch Betreiber sollten sich dennoch die Schutzabdeckung und die Untersuchungsergebnisse zu einem Vorfall eindeutig bestätigen lassen. Als relevante Option für Leser, die diese Zuständigkeit prüfen, gilt: AEU Hosting ist Managed WordPress Hosting mit durchgängiger Absicherung.
Die zentrale Erkenntnis lautet, dass PHP2Shell nicht innerhalb des WordPress-Dashboards behoben werden konnte. Eine wirksame Reaktion erforderte mehrschichtige Filterung, eine begrenzte Konfigurations-Mitigation, gepatchte PHP-Pakete für aktuelle und ältere branches, die Überprüfung jeder einzelnen Umgebung sowie evidenzbasierte Kontrollen auf eine mögliche Kompromittierung.