php2shell: Was die PHP-Lücke über die Angriffe von morgen verrät

Am 21. Oktober 2026 um 16 Uhr wurde es für viele Betreiber ernst. Das PHP-Projekt veröffentlichte Patches für zwei kritische Lücken im Kern der Sprache, die unter dem Namen php2shell bekannt wurden. Wer PHP im Netz betreibt, also rund drei Viertel aller Websites, war betroffen. Noch am selben Abend liefen die ersten Massenscans. Einige Betreiber nahmen ihre Seiten vom Netz, Administratoren schoben Nachtschichten.

Der Fall ist mehr als eine weitere Sicherheitswarnung. Er zeigt in Zeitraffer, wie Angriffe im Jahr 2026 ablaufen, und er zeigt, was Unternehmen brauchen, um ihnen zuvorzukommen. Wir haben php2shell auf unseren eigenen Servern und denen unserer Kunden begleitet. Das ist, was wir daraus mitnehmen.

Was am 21. Oktober passiert ist

Die beiden Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9,2 bewertet. Die erste erlaubt die Ausführung fremden Codes, wenn PHP beim Aufräumen einer Anfrage der Speicher ausgeht. Die zweite lässt Reste einer Anfrage in der nächsten weiterleben, auf demselben Worker. Zusammen ergeben sie das, was Angreifer suchen: Code ausführen, ohne sich anzumelden.

Betroffen ist jedes PHP, das Webanfragen bedient: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Die Patches kamen als PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gab es nur minimale Quellcode-Rückportierungen, für 7.3 und älter nichts. Die Distributionen zogen nach: Ubuntu veröffentlichte seine Pakete am 21. Oktober um 16:07 Uhr, Debian ebenfalls noch am selben Tag.

Dann ging es schnell. Noch vor Ablauf der Sperrfrist kursierten laut Amazon Threat Intelligence die ersten Proof-of-Concept-Exploits, die ersten Angriffsversuche gegen Honeypots folgten innerhalb von Stunden. Die US-Behörde CISA nahm beide Lücken in ihren Katalog aktiv ausgenutzter Schwachstellen auf. Am 23. Oktober schob das PHP-Projekt ein weiteres Advisory nach (CVE-2026-115560), ein zusätzlicher Weg über den Upload-Fortschritt von Sitzungen.

Warum diese Lücke anders war

Die meisten Sicherheitswarnungen, die Unternehmen erreichen, betreffen eine Anwendung: ein WordPress-Plugin, ein Shop-Modul, eine Bibliothek. Man aktualisiert das Plugin und ist fertig.

php2shell saß darunter. PHP verarbeitet die bösartige Anfrage, bevor eine Zeile der eigentlichen Anwendung läuft. Deshalb hilft kein Login, keine Rollenverwaltung, kein Plugin-Update. Datadog Security Labs formuliert es nüchtern: Die Authentifizierung der Anwendung kann den Angriff nicht blockieren. Und die Notlösung, die in Foren kursierte (den Upload-Fortschritt in der PHP-Konfiguration abschalten), schließt nur einen der Wege. Nur das Update schließt alle.

Für Unternehmen heißt das: Die Frage war nicht „Welches Plugin nutzen wir?“, sondern „Welches PHP läuft auf welchem Server, aus welcher Quelle, und wer spielt das Update ein?“. Wer diese Frage am 21. Oktober nicht binnen Minuten beantworten konnte, hatte ein Problem.

Drei Muster, die php2shell über morgen verrät

Der Angriff kommt vor dem Patch. Amazon beobachtete den ersten Angriffsversuch am 17. Oktober, vier Tage vor der Veröffentlichung. Wie die Angreifer so früh an Details kamen, ist offen; laut Huntress waren Informationen zu den Lücken am 20. Oktober im Netz. Die Konsequenz formuliert Amazon selbst: Untersuchungen müssen am frühesten bekannten Angriffsdatum beginnen, nicht am Tag der Veröffentlichung. Wer seine Logs nur ab dem 21. Oktober prüft, schaut an der Lücke vorbei.

Die Scanner brauchen Stunden, nicht Wochen. Zwischen Patch und Massenscan lagen keine Tage mehr. Was früher ein Wochenende Puffer war, ist heute ein Nachmittag. Ein Update, das im nächsten Wartungsfenster „irgendwann in den nächsten zwei Wochen“ eingeplant ist, kommt zu spät.

KI macht beides schneller. Im Oktober veröffentlichten TÜV-Verband und BSI ihre KI-Sicherheitsstudie 2026: 17 Prozent der befragten Unternehmen meldeten in den vergangenen zwölf Monaten einen bestätigten oder vermuteten KI-gestützten Angriff. Bei rund 40 Prozent dieser Fälle ging es um automatisierte Angriffe auf IT-Schwachstellen. Nur 11 Prozent der Unternehmen, die KI einsetzen, haben eigene Prozesse für solche Vorfälle. Wie Angreifer KI nutzen, um Lücken zu finden und Angriffe in Serie zu fahren, haben wir in KI gegen KI beschrieben. php2shell war der erste große Fall, an dem man das Tempo messen konnte.

Vorausschauen statt reagieren

Man kann die nächste Lücke nicht vorhersagen. Man kann aber vorhersagen, dass sie kommt, und sich so aufstellen, dass sie keinen Notfall auslöst. Vier Dinge haben sich bei php2shell bewährt.

Ein Inventar, das die Frage beantwortet. Welcher Server läuft mit welchem PHP, aus Distributionspaketen oder Fremdquellen, und wann endet der Support? Wer das in einer Tabelle hat, weiß in Minuten, wo es brennt. Wer PHP 8.1 oder älter betreibt, wusste am 21. Oktober außerdem: Hier kommt kein regulärer Patch. Das ist ein Migrationsprojekt, kein Update.

Sicherheitsupdates in Stunden, nicht in Wochen. Die Distributionen hatten die Patches am 21. Oktober. Alles danach ist eine Frage der eigenen Abläufe. Für unsere Server und die unserer Kunden übernimmt das unser Wartungsdienst Sentinel: Er prüft alle zehn Minuten offene Sicherheitsupdates, gleicht sie mit den Hinweisen der Distribution und dem CISA-Katalog ab und spielt sie ein, mit Sicherung vorher und Prüfung danach. Bei php2shell hat uns das auch eine Lehre beschert, die wir offen in der Chronik dokumentiert haben: Damals wartete Sentinel noch auf das Wartungsfenster am nächsten Morgen, 14 Stunden nach dem Hinweis von Ubuntu. Seitdem werden Sicherheitsupdates sofort eingespielt und nur gewöhnliche Updates warten. Lernen aus dem Fall gehört dazu.

Die Angriffsfläche von außen kennen. Ein Patch-Dienst schließt die Lücke im System. Er sieht nicht, ob die Anwendung darüber selbst angreifbar ist, ob ein vergessenes Staging-System am Netz hängt oder ein alter Upload-Ordner Code ausführt. Dafür gibt es den Blick von außen, den ein Angreifer hat: einen Penetrationstest. Wir bieten ihn aktuell kostenfrei an, gerade weil Fälle wie php2shell zeigen, wie viel unbeachtete Fläche es gibt.

Logs ab dem frühesten Datum prüfen. Für php2shell heißt das: ab dem 17. Oktober. Auffällig sind sehr große oder tief verschachtelte Formulardaten, Speicherfehler beim Start einer Anfrage, Abstürze einzelner Worker und Shells, die von Webserver- oder PHP-Prozessen gestartet wurden. Kein einzelnes Signal beweist etwas; die Kombination schon.

Checkliste für die nächste Woche

1. PHP-Stand prüfen, und zwar das Paket, nicht nur die Versionsnummer. Unter Ubuntu und Debian zeigt apt-get changelog php8.3 | grep -m1 CVE-2026-109619, ob der Fix im installierten Paket steckt.
2. Fremdquellen finden. PHP aus Docker-Images, Hosting-Paneelen oder eigenen Builds bekommt das Update nicht von der Distribution.
3. PHP 8.1 und älter auf eine unterstützte Version heben. Das ist überfällig, php2shell hat es nur sichtbar gemacht.
4. Logs ab dem 17. Oktober auf die oben genannten Muster durchsehen. Bei Verdacht: nicht patchen und hoffen, sondern Spuren sichern.
5. Abläufe festlegen: Wer spielt Sicherheitsupdates ein, in welcher Frist, mit welcher Sicherung? Wenn die Antwort „der Kollege, wenn er Zeit hat“ lautet, ist das der Punkt, an dem es beim nächsten Mal hakt.

Fazit

php2shell war kein Ausnahmefall, sondern eine Vorschau. Angriffe beginnen vor dem Patch, Scanner brauchen Stunden, und KI drückt beide Zeiten weiter. Unternehmen gewinnen nicht durch schnellere Reaktion am Tag X, sondern durch Vorbereitung: ein Inventar, das sofort Antworten gibt, Sicherheitsupdates, die ohne Nachtschicht laufen, und den regelmäßigen Blick von außen.

Wenn Sie wissen wollen, wo Ihre Systeme heute stehen, fangen Sie mit dem Blick von außen an: Unser Sicherheits-Check ist kostenfrei, vertraulich und endet mit einer priorisierten Liste statt mit einem Bauchgefühl.