php2shell: Wie schnell die Hoster die kritische PHP-Lücke geschlossen haben

Am 20. Oktober kündigte das PHP-Projekt für den nächsten Tag ein kritisches Sicherheitsrelease an, um 14 Uhr UTC. Am 21. Oktober um 16 Uhr deutscher Zeit standen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bereit. Was danach passiert, liegt bei den meisten Website-Betreibern nicht mehr in der eigenen Hand: Wer Shared Hosting oder Managed WordPress nutzt, ist so lange angreifbar, bis der Hoster das Update auf seine Server bringt.

Wir betreuen eine Reihe von Websites und Anwendungen auf verschiedenen Hostern, eigene und die von Kunden. Für 27 davon haben wir an diesem Abend mitgeschrieben, wann die neue Version ankam. Das Ergebnis ist kein Hoster-Test, aber ein ehrlicher Blick darauf, wie unterschiedlich schnell das geht.

Was php2shell ist

Laut Sicherheitshinweis des PHP-Projekts stecken hinter dem Namen zwei Fehler im Umgang mit dem Speicher zwischen zwei Anfragen. Bei CVE-2026-109618 kann ein Abbruch wegen Speichermangels Daten in einem halb fertigen Zustand hinterlassen, die PHP beim Aufräumen für gültig hält. Bei CVE-2026-109619 bleibt interner Zustand einer Anfrage liegen, nachdem sein Speicher schon freigegeben ist, und die nächste Anfrage im selben Prozess greift darauf zu. Beide sind mit CVSS 9.2 bewertet und erlauben im schlimmsten Fall, eigenen Code auf dem Server auszuführen.

Betroffen ist jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten ist das Risiko bei mod_php. Eine Anmeldung braucht der Angreifer nicht, und der Angriff greift, bevor WordPress oder ein Plugin überhaupt Code ausführt. Ein Sicherheits-Plugin sieht davon also nichts.

Wie weit Angriffe schon laufen, schätzen die Quellen unterschiedlich ein. Das kanadische Cyber Centre meldete am 21. und 23. Oktober einen öffentlichen Proof of Concept, aber noch keine festgestellte Ausnutzung (Warnmeldung AL26-026). Laut Help Net Security hat Amazon einen Ausnutzungsversuch schon am 17. Oktober gesehen, vier Tage vor der Veröffentlichung.

Unsere Messung: 27 Systeme, sieben Hoster und ein eigener Server

Gemessen haben wir von außen und nur lesend. Die meisten Hoster nennen die PHP-Version im Antwortkopf X-Powered-By. Den haben wir bei Hostinger und STRATO alle fünf Minuten abgefragt, und zwar auf wp-login.php, weil diese Seite nie aus dem Cache kommt und PHP sicher läuft. Bei Raidboxes stand die Version im Systembericht von WooCommerce. All-Inkl blendet den Antwortkopf aus, dort hat eine einzeilige Prüfdatei die Version ausgegeben und wurde danach gleich wieder gelöscht. Bei united-domains und CheckDomain war die Version von außen nicht ablesbar.

Zwei Einschränkungen gehören dazu. Wir haben unsere eigenen Konten gemessen, keine Stichprobe über alle Server eines Hosters. Große Hoster rollen Updates oft Server für Server aus, andere Kunden können früher oder später dran gewesen sein. Und zwischen dem 22. und dem 26. Oktober haben wir bei Hostinger nicht gemessen, wann genau 8.3.36 kam, wissen wir deshalb nicht.

Was wir daraus mitnehmen

Die Spanne ist groß, und du siehst sie nicht

Zwischen dem schnellsten und dem langsamsten Hoster in unserer Messung liegen mindestens 13 Stunden, eine ganze Nacht. Von außen sieht man einer Website nicht an, ob ihr Server schon gepatcht ist. Wer nicht selbst nachsieht, weiß es nicht.

Der eigene Server ist so schnell wie sein langsamster Schritt

Auf unserem eigenen Server läuft eine Anwendung in Docker, gebaut auf dem offiziellen PHP-Image. Das Image mit der Nummer 8.4.27 erschien um 17:45 Uhr, die Fassung für normale Intel- und AMD-Server erst um 18:47 Uhr. Unser Neubau lief um 18:51 Uhr. Damit er überhaupt das neue Basisimage zieht und nicht das alte aus dem Zwischenspeicher nimmt, mussten wir die Bauanweisung ändern. Seitdem holt jeder Build das aktuelle Image.

Coolify, die Plattform, mit der wir diesen Server verwalten, hat ihr Update mit der gepatchten PHP-Version schon zwölf Minuten nach dem Release veröffentlicht. Bei uns kam es trotzdem erst mit dem nächtlichen automatischen Update an. Schnelle Hersteller nützen wenig, wenn das Update auf deinem System liegen bleibt.

Alte PHP-Zweige bekommen nichts mehr

Ein System lief noch auf PHP 8.1. Für 8.1 und älter baut das PHP-Projekt keine Releases mehr, es gibt nur minimale Korrekturen im Quelltext für alle, die PHP selbst übersetzen. Auf Shared Hosting hilft dort nur der Wechsel auf einen unterstützten Zweig. Ein anderes System stand schon vor dem Sicherheitsrelease fünf Releases zurück, auf 8.2.29 statt 8.2.34. Die gute Nachricht: Das Sicherheitsrelease hat es mitgezogen, bei der Nachmessung lief es auf 8.2.35.

Ohne PHP keine PHP-Lücke

Unsere Hauptseite hafenstudios.com war nicht betroffen, weil sie aus statischen HTML-Dateien besteht. Für eine WordPress-Seite ist das keine Option, aber es zeigt, warum Teile, die kein PHP brauchen, auch keins ausführen sollten.

So prüfst du deine PHP-Version in WordPress

1. Im Dashboard: Werkzeuge, Website-Zustand, Reiter Bericht, dann den Abschnitt Server aufklappen. Dort steht die PHP-Version, mit der WordPress gerade läuft.
2. Mit der Tabelle vergleichen: Gepatcht ist dein Zweig ab der Nummer in der Spalte „Gepatcht ab“.
3. Zusätze richtig lesen: Hinter der Nummer kann ein Kürzel des Hosters stehen, etwa 8.3.36-nmm1. Maßgeblich ist die Nummer davor.

Eine Ausnahme: Manche Linux-Distributionen und Hoster bauen die Korrektur in ihre eigene Fassung ein, ohne die Nummer zu ändern. Steht bei dir eine ältere Nummer und dein Hoster sagt, er habe gepatcht, ist das kein Widerspruch. Dann zählt seine schriftliche Auskunft.

Wer viele Seiten betreut, kann ab WordPress 6.9 auch per REST-Schnittstelle nachsehen, mit einem Anwendungspasswort und nur lesend: /wp-json/wp-abilities/v1/abilities/core/get-environment-info/run liefert unter anderem die PHP-Version.

Wenn dein Hoster noch nicht gepatcht hat

• Nachfragen. Ein kurzer Satz an den Support genügt: Wann kommt PHP 8.x.y mit der Korrektur für CVE-2026-109618 und CVE-2026-109619? Die Antwort zeigt dir auch, wie ernst dein Hoster das nimmt.
• Den Zweig wechseln. Viele Hoster bieten mehrere PHP-Versionen zur Auswahl an. Ist ein anderer Zweig schon gepatcht, kannst du nach einem kurzen Test dorthin wechseln. Vorher ein Backup, danach Startseite, Login und Formulare durchklicken.
• Eine Firewall als Brücke. Cloudflare hat Regeln gegen bekannte Angriffswege ausgerollt, auch im kostenlosen Tarif. Das PHP-Projekt schreibt aber deutlich, dass es keine vollständige Abhilfe gibt. Die Firewall ersetzt das Update nicht.
• Bei eigenen Servern: Pakete aktualisieren, Container mit frischem Basisimage neu bauen und danach alle PHP-Prozesse neu starten. Die Einstellungen, mit denen das PHP-Projekt die Zeit bis zum Update überbrücken lässt, stehen im Sicherheitshinweis.

Am 23. Oktober kam ein Nachtrag: Eine dritte Lücke, CVE-2026-115560, steckt in der Fortschrittsanzeige für Uploads in Sitzungen. Sie greift nur, wenn eine Anwendung das Speicherformat ihrer PHP-Sitzungen zur Laufzeit umstellt. WordPress selbst nutzt keine PHP-Sitzungen, in Frage kämen allenfalls Plugins, die das tun. Die Korrektur kommt mit dem nächsten regulären Release, bis dahin empfiehlt das PHP-Projekt session.upload_progress.enabled=0. Auf Shared Hosting setzt das nur der Hoster.

Und wenn du ohnehin gerade aufräumst: PHP-Updates sind nur die eine Hälfte. Warum veraltete Plugins das größere Dauerproblem sind, steht in unserem Beitrag über das Aktualisieren von WordPress-Plugins. Wie alt die Mindestanforderungen im Plugin-Verzeichnis teilweise noch sind, zeigt unsere Auswertung: 8.131 Plugins nennen noch PHP 5.

Häufige Fragen