Kurz gesagt: Die PHP2Shell-Zeitlinie umfasst bisher vier belegte Daten: einen ersten beobachteten Angriffsversuch am 17.10., die Vorankündigung durch php.net am 20.10., die Patches am 21.10. um 16 Uhr deutscher Zeit und einen weiteren Hinweis zu CVE-2026-115560 am 23.10.2026. Für Betreiber folgt daraus: patchen, alle PHP-Prozesse neu starten und Logs spätestens ab dem 20.10. sichern.
Warum eine PHP2Shell-Zeitlinie für Betreiber wichtig ist
Bei einer Lücke dieser Schwere zählt nicht nur, ob Ihr Server heute gepatcht ist. Entscheidend ist auch, wie lange er vorher verwundbar war. Dieses Zeitfenster bestimmt, welche Logs Sie sichern, welche Dateien Sie prüfen und ob Sie eine Kompromittierung mit gutem Grund ausschließen können.
PHP2Shell betrifft PHP selbst, nicht ein einzelnes CMS. Zwei kritische Lücken, CVE-2026-109618 und CVE-2026-109619, erlauben die Ausführung von Schadcode aus der Ferne ohne Anmeldung. Beide sind mit CVSS v4.0 9.2 bewertet. Eine verständliche Einführung finden Sie unter Was ist PHP2Shell?.
Die folgende Chronologie enthält nur Daten, die zum Stand 25.10.2026 belegt sind. Wo eine Angabe auf Medienberichten beruht, ist das vermerkt.
| Datum | Ereignis | Grundlage |
|---|---|---|
| 17.10.2026 | Erster beobachteter Angriffsversuch (Amazon) | Medienberichte |
| 20.10.2026 | Vorankündigung durch php.net | php.net |
| 21.10.2026, 14:00 UTC | Veröffentlichung der Patches (16 Uhr deutscher Zeit) | php.net |
| 23.10.2026 | Hinweis zu CVE-2026-115560 | php.net |
| 25.10.2026 | Stand dieser Übersicht | – |
17. Oktober: der erste beobachtete Angriffsversuch
Laut Medienberichten wurde am 17.10.2026 ein erster Angriffsversuch beobachtet, gemeldet von Amazon. Das war vier Tage vor den Patches. Es gab also einen Zeitraum, in dem bereits Angriffe versucht wurden, aber noch kein Update existierte.
Ob und wie viele Angriffe in dieser Phase erfolgreich waren, ist nicht belegt. Wichtig ist die Folge für Ihre eigene Prüfung: Ein Server, der heute gepatcht ist, kann vorher kompromittiert worden sein. Ein Patch entfernt keine eingeschleuste Schadsoftware und beweist nicht, dass vorher nichts passiert ist.
20. und 21. Oktober: Vorankündigung und Patches
Am 20.10.2026 kündigte das PHP-Projekt die Sicherheitsupdates auf php.net an. Am 21.10.2026 um 14:00 UTC, also 16 Uhr deutscher Zeit, folgten die behobenen Versionen.
| Zweig | Letzter verwundbarer Stand | Behoben in |
|---|---|---|
| PHP 8.5 | 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.34 | 8.2.35 |
Für PHP 8.1 und älter gibt es keine offiziellen Updates mehr, nur minimale Quell-Backports für 7.4, 8.0 und 8.1. Laut Fachpresse sind nahezu alle Versionen bis zurück zu PHP 5.4 betroffen. Betroffen sind die Betriebsarten PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php, wo ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft.
Distributionen und Hoster spielen teils Backports ein. Dann zeigt etwa Plesk weiter 8.2.34 an, obwohl der Server gepatcht ist. Maßgeblich sind der Paketstand und die Bestätigung des Anbieters, nicht die angezeigte Versionsnummer. Wie Sie das sauber prüfen, steht unter PHP-Version und Patchstand richtig prüfen.
23. Oktober: Hinweis zu CVE-2026-115560
Am 23.10.2026 veröffentlichte das PHP-Projekt einen weiteren Hinweis, diesmal zu CVE-2026-115560. Eine Ausnutzung ist danach nur bei ungewöhnlicher Konfiguration möglich: In der Konfiguration steht der serialize_handler php_binary oder php_serialize, die Anwendung stellt ihn vor session_start() per ini_set() auf php um, und Session-Upload-Progress ist aktiv.
Die Abhilfe ist einfach und sollte unabhängig davon gesetzt werden, ob Sie diese Konstellation bei sich kennen:
; in php.ini, im FPM-Pool oder in der Serverkonfiguration
; nicht per ini_set() oder .user.ini
session.upload_progress.enabled = 0
Danach alle PHP-Worker neu starten. Der vollständige Advisory soll mit dem nächsten regulären Bugfix-Release folgen. Bis dahin bleibt die Einstellung die empfohlene Übergangslösung.
Stand 25. Oktober: Lage und offene Fragen
Das BSI hat Warnstufe 3 / Orange ausgerufen. Es empfiehlt das sofortige Update und, falls das nicht sofort möglich ist, die Webserver vorübergehend vom Netz zu nehmen. Das BSI rechnete mit schneller großflächiger Ausnutzung; bestätigte erfolgreiche Angriffe in der Breite waren laut BSI zunächst nicht bekannt. Die Einordnung des BSI fasst die Seite Was das BSI zu PHP2Shell empfiehlt zusammen.
Cloudflare meldete beobachtete Angriffsversuche und hat Schutzregeln ausgerollt, warnt aber, dass Regeln anhand der Anfragedaten allein nicht genügen. Palo Alto Networks (Unit 42) zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen. Bestätigte Indicators of Compromise sind nicht veröffentlicht; die Erkennung beruht auf Verhaltensanalyse.
Einige Anbieter haben Websites vorsorglich offline genommen. Das bedeutet nicht automatisch, dass diese Seiten gehackt wurden. Offen ist zum Stand dieser Übersicht vor allem, wie viele Server in der Zeit vor dem Patch tatsächlich kompromittiert wurden.
Was die Zeitlinie für Ihre Logs und Prüfungen bedeutet
Aus den Daten ergeben sich drei Zeiträume: vor dem 17.10., zwischen dem 17.10. und Ihrem eigenen Patch- und Neustart-Zeitpunkt sowie danach. Der mittlere Zeitraum ist der kritische. Je länger er bei Ihnen dauerte, desto gründlicher sollte die Prüfung ausfallen.
Die Fachpresse rät, Server-Logs ab dem 20.10.2026 aufzubewahren. Sichern Sie vorhandene ältere Logs mit, bevor die automatische Rotation sie löscht.
Ein einfacher Weg, Logs unverändert zu sichern und den Stand festzuhalten:
# Logs gesammelt sichern (Pfade an Ihr System anpassen)
sudo tar czf /root/logs-sicherung-$(date +%F).tar.gz /var/log/apache2 /var/log/nginx /var/log/php*
# Prüfsumme für den späteren Nachweis
sha256sum /root/logs-sicherung-*.tar.gz
# Wie lange hält das System Logs vor?
grep -R "rotate" /etc/logrotate.d/
Notieren Sie außerdem, wann genau das Update eingespielt und wann die PHP-Prozesse neu gestartet wurden. Neue Dateien allein schützen nicht, solange alte Prozesse im Speicher laufen. Wie Sie gesicherte Logs auswerten, beschreibt der Ratgeber Webserver-Logs nach einem Angriff auswerten.
Wie hilft PHP SOS konkret?
- Wir bestimmen mit Ihnen das tatsächliche Verwundbarkeitsfenster Ihres Servers: Paketstand, Patch-Zeitpunkt, Neustart aller Worker.
- Wir sichern Logs und Systemzustand nachvollziehbar, bevor etwas verändert wird.
- Wir prüfen auf Verhaltensauffälligkeiten wie neue PHP-Dateien, fremde Prozesse und ungewöhnliche ausgehende Verbindungen.
- Wir dokumentieren das Ergebnis so, dass Geschäftsführung, Datenschutzbeauftragte und Versicherer damit arbeiten können.
Den Ablauf im Einzelnen beschreibt unsere PHP2Shell-Soforthilfe.
Häufige Fragen
Wann wurden die PHP2Shell-Patches veröffentlicht?
Das PHP-Projekt hat die behobenen Versionen am 21.10.2026 um 14:00 UTC veröffentlicht, also um 16 Uhr deutscher Zeit. Behoben sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Ab welchem Datum sollte ich Server-Logs aufbewahren?
Die Fachpresse rät, Logs ab dem 20.10.2026 aufzubewahren. Weil laut Medienberichten schon am 17.10. ein erster Angriffsversuch beobachtet wurde, lohnt es sich, auch vorhandene ältere Logs zu sichern, bevor die Rotation sie löscht.
Ist CVE-2026-115560 genauso gefährlich wie die beiden ersten Lücken?
Laut Hinweis vom 23.10.2026 ist eine Ausnutzung nur bei einer ungewöhnlichen Session-Konfiguration möglich. Als Abhilfe gilt session.upload_progress.enabled=0, bis das nächste reguläre Bugfix-Release erscheint.
Gibt es bestätigte Indicators of Compromise zu PHP2Shell?
Nein, zum Stand 25.10.2026 sind keine bestätigten Indicators of Compromise veröffentlicht. Die Erkennung stützt sich auf Verhaltensanalyse, etwa ungewöhnliche Prozesse, neue Dateien und auffällige Verbindungen.