PHP2Shell: wenige Stunden zwischen Leak und Angriff. Hat Ihr Hoster Wache gehalten?

Am 21. Oktober hat das PHP-Team im Eilverfahren vier neue Versionen veröffentlicht, um zwei kritische Lücken im Kern der Sprache zu schließen. Sie erlauben es, Code auf einem Server auszuführen, ohne Konto und ohne Passwort, manchmal noch bevor die Anwendung überhaupt startet. PHP betreibt WordPress, Drupal, Joomla, einen großen Teil der Onlineshops und der Websites von Gemeinden. Hier steht, was passiert ist, wie Sie erkennen, ob Sie betroffen sind, und was diese Woche zu tun ist.

Eine Woche im Zeitraffer #

• 24. August. Die Forscher von Wiz melden die Lücken an das PHP-Sicherheitsteam. Das Unternehmen Calif und OpenAI finden sie ebenfalls. Alle drei Teams haben mit KI-Modellen gearbeitet.
• 17. Oktober. Amazon gibt an, auf seinen Honeypot-Servern einen Angriffsversuch von diesem Tag entdeckt zu haben, vier Tage vor der öffentlichen Ankündigung.
• 20. Oktober. Der geplante Veröffentlichungstermin, der 22., sickert zusammen mit den Nummern der Lücken auf Hacker News durch. Noch am selben Abend zieht PHP die Veröffentlichung auf den nächsten Tag vor, 14:00 Uhr UTC.
• 21. Oktober. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen. Am selben Tag beobachtet watchTowr die ersten Angriffe in seinem Honeypot-Netz.
• 22. Oktober. Das CERT-FR, das französische nationale CERT, kennt Proofs of Concept und stellt Angriffsversuche fest.
• 23. Oktober. PHP meldet eine dritte Lücke, CVE-2026-115560, die nur seltene Konfigurationen betrifft.
• 26. Oktober. Die US-Behörde CISA nimmt beide Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen auf.

Zwischen dem Leak und den ersten beobachteten Angriffen vergingen wenige Stunden. Auf den Servern, die wir hosten, hat jemand Wache gehalten.

Warum es ernst ist: Die Lücke steckt nicht in Ihrem Code #

Normalerweise steckt eine Web-Schwachstelle in einem WordPress-Plugin, einem schlecht geschützten Formular oder einer vergessenen Bibliothek. Hier steckt sie im Motor, der den Code ausführt: CVE-2026-109618 und CVE-2026-109619, bewertet mit 9,2 von 10. Vereinfacht gesagt gibt es zwei Mechanismen.

• Der Speicher läuft im falschen Moment voll. Wenn PHP mitten im Lesen einer Anfrage der Speicher ausgeht, etwa beim Hochladen einer Datei, bricht es mit halb vorbereiteten Daten ab. Das anschließende Aufräumen behandelt diese Daten dann als gültig.
• Reste der vorherigen Anfrage. Eine Anfrage kann einen internen Zustand hinterlassen, der auf bereits freigegebenen Speicher zeigt. Die nächste Anfrage im selben Prozess nutzt ihn, bevor er zurückgesetzt wird.

Laut Wiz reichen diese Fehler mehr als zehn Jahre zurück: Jede Version seit PHP 5.4 ist von mindestens einer der beiden Lücken betroffen. Wiz gelang die Codeausführung auf den aktuellen Images von WordPress, Drupal und Joomla. Selbst eine einfache „Hello World“-Seite ist verwundbar, da die Anwendung keine Rolle spielt. Ein weiteres Risiko: das Auslesen des Serverspeichers aus der Ferne, in dem Passwörter, API-Schlüssel oder Zertifikate liegen können.

PHP stuft das Risiko für Apache mit mod_php am höchsten ein. Dort genügt eine einzige Anfrage ohne Anmeldung, um den Angriff auszulösen, bevor der Code der Website läuft. Palo Alto Networks zählt mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen.

Sind Sie betroffen? #

Ja, wenn ein Server PHP ausführt, um Besuchern zu antworten, egal auf welche Weise: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed.

• PHP 8.2, 8.3, 8.4 und 8.5: behoben in 8.2.35, 8.3.36, 8.4.27 und 8.5.12.
• PHP 7.4, 8.0 und 8.1: vom Projekt nicht mehr gepflegt. Patches Ihrer Distribution oder Ihres Anbieters, oder Migration.
• PHP 7.3 und älter, PHP 5 eingeschlossen: kein Patch. Die Migration ist Pflicht.

Zwei Fallen tauchen oft auf.

• PHP versteckt sich in anderen Produkten. Man findet es in Hosting-Panels, Netzwerkgeräten, Fachsoftware. Die CISA erinnert daran: Es ist nicht immer sichtbar.
• Die Version, die die Website ausliefert, ist nicht unbedingt die, die man glaubt. Auf einem Server können mehrere Versionen installiert sein. Fragen Sie Ihren Dienstleister, welche tatsächlich den Besuchern antwortet.

Was diese Woche zu tun ist #

1. PHP selbst aktualisieren, nicht nur WordPress oder die Plugins. Die Linux-Distributionen haben die Patches vorab erhalten, ihre Pakete sind verfügbar.
2. Alle PHP-Prozesse neu starten nach dem Update. Sonst bleibt der alte Code im Speicher, und der Server bleibt verwundbar, selbst mit dem richtigen Paket.
3. Sich nicht auf Workaround-Einstellungen verlassen. Das PHP-Team sagt es selbst: Keine davon macht eine Installation sicher, nur das Update behebt die Lücke. Eine Ausnahme: Für die dritte Lücke genügt es, session.upload_progress bis zur nächsten Version zu deaktivieren.
4. Isolieren, was sich nicht aktualisieren lässt. Das empfiehlt das CERT-FR für nicht mehr gepflegte Zweige: den Zugang aus dem Internet kappen, dann migrieren. Beachten Sie auch, dass PHP 8.2 nach dem 31. Dezember 2026 keine Patches mehr erhält.
5. In die Logs schauen. Warnzeichen laut Wiz und CISA: ungewöhnliche Formular-Uploads, gefolgt von Speicherfehlern oder Serien von 500-Fehlern, ungewöhnlich lange Session-Cookies, PHP-Prozesse, die ohne Grund neu starten oder Befehle ausführen und Werkzeuge herunterladen.
6. Die Geheimnisse wechseln, wenn der Server vor dem Update exponiert war. Ein Update schließt die Tür, es holt niemanden heraus, der schon drin ist. Und der Speicher kann Passwörter oder Schlüssel preisgegeben haben.

Was diese Woche über Hosting sagt #

Jede Sprache hatte oder wird eine Woche wie diese haben. Die richtige Frage ist nicht, ob PHP sicher ist. Sie lautet, wer Ihre Server überwacht und wie schnell der Patch dort ankommt.

Für die Anwendungen, die wir hosten und betreuen, wird die Plattform aktuell gehalten und Tag und Nacht überwacht, auf unseren Servern in Frankreich. Eine Warnung wie diese wird bei uns bearbeitet, ohne dass Sie anrufen müssen: Patch eingespielt, Kontrolle danach, nächtliche Backups griffbereit.

Liegt Ihre PHP-Website oder -Anwendung bei einem anderen Dienstleister oder läuft sie auf einer Version, die nicht mehr gepflegt wird? Wir schauen es uns gemeinsam mit Ihnen an: was exponiert ist, was aktualisiert werden muss, und falls nötig ein Migrationsplan oder die Übernahme der Wartung.

Quellen #

• PHP, Sicherheitsmeldungen vom 20., 21. und 23. Oktober 2026: behobene Versionen, Hinweise zu CVE-2026-109618 und CVE-2026-109619, Informationshinweis zu CVE-2026-115560.
• CERT-FR, Bulletin CERTFR-2026-ALE-014, Multiples vulnérabilités dans PHP (20. Oktober 2026, aktualisiert am 26., auf Französisch).
• CERT-EU, Security Advisory 2026-018, Critical Vulnerabilities in PHP (23. Oktober 2026).
• CISA, Critical Vulnerabilities in PHP Require Immediate Patching (21. Oktober 2026, Aktualisierung vom 26.: Aufnahme in den KEV-Katalog).
• Wiz Research, PHP2Shell: AI uncovers critical RCE vulnerabilities (21. Oktober 2026).
• watchTowr, PHP2Shell FAQ: Chronologie und beobachtete Ausnutzung.
• Unit 42 (Palo Alto Networks), Threat Brief: PHP2Shell (aktualisiert am 25. Oktober 2026).
• The Hacker News, Angriffsversuch vier Tage vor der Veröffentlichung, laut Amazon.