PHP2Shell-Patches beheben kritisches Risiko für WordPress-Server
PHP2Shell ist die Sammelbezeichnung für zwei kritische PHP-Schwachstellen, die am 21. Oktober 2026 öffentlich bekannt gegeben wurden. PHP ist die serverseitige Programmiersprache, auf der WordPress läuft. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 könnten es einem Angreifer ermöglichen, ohne Authentifizierung Schadcode auf einem betroffenen Server auszuführen, also ohne zuvor ein gültiges Konto anzugeben oder sich anzumelden. Beide erhielten nach CVSS 4.0, dem Common Vulnerability Scoring System zur Bewertung des Schweregrads von Sicherheitslücken, den kritischen Wert 9,2.
Die Schwachstellen betreffen die Art und Weise, wie PHP bei der Verarbeitung von Anfragen mit Speicher umgeht. Eine erfolgreiche Ausnutzung könnte Websites und die auf demselben Server gespeicherten Daten kompromittieren. Jede WordPress-Installation, die eine betroffene PHP-Version verwendete, war daher potenziell gefährdet, doch das Problem lag nicht in WordPress selbst. PHP2Shell betraf die PHP runtime, also die zugrunde liegende Server-Software, die PHP-Code interpretiert und ausführt, und nicht WordPress core, ein Plugin oder ein Theme. Eine Aktualisierung dieser WordPress-Komponenten würde die anfällige PHP-Software nicht korrigieren.
Das PHP-Entwicklungsteam veröffentlichte am 21. Oktober Notfall-Sicherheitsupdates für PHP 8.2, 8.3, 8.4 und 8.5. Sicherheitskorrekturen für ältere PHP-Versionen kamen von Drittanbietern. Kinsta zufolge hatten seine Engineering- und Sicherheitsteams bereits mit den Vorbereitungen begonnen, bevor die offiziellen Korrekturen, allgemein als Patches bezeichnet, verfügbar wurden. Der Anbieter führte zunächst Maßnahmen ein, die die Möglichkeiten einer Ausnutzung verringern sollten, während er die korrigierten PHP-Builds prüfte und bereitstellte.
Eine vorübergehende Schutzebene stammte von Cloudflares Web Application Firewall (WAF), einem Dienst, der eingehende Webanfragen untersucht und Traffic blockiert, der schädlichen Mustern entspricht. Laut Kinsta hatte Cloudflare bereits vor der öffentlichen Bekanntgabe Schutzmaßnahmen eingerichtet, die Versuche zur Ausnutzung von PHP2Shell erkennen sollten. Kinsta aktivierte die entsprechenden Schutzmaßnahmen in seiner gesamten Hosting-Infrastruktur, sodass der Traffic gefiltert werden konnte, bevor er die gehosteten Websites erreichte. Diese Schutzmaßnahmen auf Edge-Ebene, also am äußeren Rand des Hosting-Netzwerks eingesetzte Kontrollen, blieben aktiv, während die PHP-Updates installiert wurden.
Kinsta änderte außerdem die PHP-Konfigurationseinstellungen in seinen Hosting-Umgebungen, um die potenzielle Gefährdung zu begrenzen. Während der Reaktion auf den Vorfall tauschte das Unternehmen mit seinem Partner für den Schutz vor Schwachstellen, Patchstack, Informationen über beobachtete Bedrohungen und Angriffsmuster aus. Kinsta betonte, dass die Firewall- und Konfigurationsmaßnahmen nur vorübergehende Schutzvorkehrungen und kein Ersatz für die Korrektur der PHP runtime selbst waren.
Nachdem das PHP-Team seine Korrekturen veröffentlicht hatte, prüfte Kinsta die gepatchten PHP-Pakete, also installierbare Builds der Server-Software, und stellte sie auf der gesamten Plattform bereit. Der Rollout umfasste PHP 7.4 bis PHP 8.5, einschließlich der von Kinstas PHP-Paketanbieter Freexian bereitgestellten Patches für ältere Versionen. Da PHP zentral auf Hosting-Ebene verwaltet wurde, mussten Kunden weder eine separate Korrektur installieren noch manuell die Version wechseln. Der Rollout umfasste sowohl Live-Sites als auch staging environments, also Testkopien, mit denen Änderungen vor ihrer Übernahme auf eine öffentliche Website geprüft werden.
Kinsta kennzeichnete den Vorfall am 22. Oktober 2026 um 08:26 UTC auf seiner öffentlichen Statusseite als behoben. Das Unternehmen erklärte, alle Websites hätten die erforderlichen Schutzmaßnahmen und Sicherheitsupdates erhalten. Während des Vorfalls überwachten seine Teams verdächtige Aktivitäten, untersuchten Websites, die offenbar angegriffen worden waren, manuell und führten zusätzliche Stichproben auf Anzeichen einer Kompromittierung durch. Kinsta meldete, auf seiner Plattform keine Hinweise auf erfolgreiche PHP2Shell-Kompromittierungen gefunden zu haben. Diese Aussage beschreibt die durch die eigene Überwachung verfügbaren Erkenntnisse und beweist nicht, dass es andernorts zu keiner Ausnutzung kam.
Laut Kinsta müssen Kunden ihre Websites wegen PHP2Shell weder offline nehmen noch einen weiteren Patch installieren oder die PHP-Version wechseln. Vorsorglich ausgesetzte Umgebungen können wieder aktiviert werden, da Kinsta eigenen Angaben zufolge auch ausgesetzte Umgebungen aktualisiert hat. Kunden sollten WordPress core, Plugins und Themes im Rahmen der routinemäßigen Wartung weiterhin aktualisieren. Diese Updates betreffen jedoch eine andere Sicherheitsebene und ersetzen nicht die PHP-Korrekturen auf Server-Ebene.
Kunden können die konfigurierte PHP-Version einsehen, indem sie in MyKinsta den Bereich Sites öffnen, die Website auswählen, zu Tools wechseln und anschließend PHP settings aufrufen. Die angezeigte Version allein gibt jedoch möglicherweise keinen Aufschluss darüber, ob eine Korrektur vorhanden ist. Einige Maintainer verwenden backported security fixes, bei denen eine Sicherheitskorrektur zu einer älteren Softwareversion hinzugefügt wird, ohne deren offizielle Versionsnummer auf die neueste Version anzuheben. Website-Betreiber, die weiterhin unsicher sind, können über MyKinsta das rund um die Uhr erreichbare Supportteam von Kinsta bitten, den Patch-Status einer bestimmten Umgebung zu bestätigen. Agenturen können außerdem Kinstas öffentlichen Vorfallsbericht an Kunden weitergeben, da er den Rollout und die Behebung dokumentiert.
Für Betreiber, die prüfen, wo die Verantwortung für die Serversicherheit liegen sollte, bietet AEU Hosting vollständig verwaltetes und durchgängig abgesichertes WordPress-Hosting an. PHP2Shell zeigt, warum diese Unterscheidung wichtig ist: Ein Update über das WordPress-Dashboard kann keine Schwachstelle in der PHP runtime beheben. Eine Bestätigung muss daher von der Stelle kommen, die die PHP-Software des Servers verwaltet.