Kurz gesagt: Das Zeitfenster zwischen Patch und Angriff war bei PHP2Shell negativ: Laut Medienberichten gab es einen ersten Angriffsversuch schon am 17. Oktober 2026, vier Tage vor den Updates. Für Betreiber zählt deshalb nicht die Frage „Wie viel Zeit bleibt?“, sondern „Wie lange ist mein Server offen?“. Dieses persönliche Fenster endet erst, wenn das Update installiert und alle PHP-Prozesse neu gestartet sind.
Der Aufhänger: Angriffe vor dem Patch
Lange galt eine bequeme Annahme: Zwischen Sicherheitsupdate und ersten Angriffen vergehen einige Tage, genug Zeit für das nächste Wartungsfenster. PHP2Shell hat diese Annahme widerlegt. Laut Medienberichten, die sich auf Amazon berufen, wurde ein erster Angriffsversuch bereits am 17. Oktober beobachtet. Cloudflare berichtete ebenfalls von frühen Angriffen. Die Patches kamen am 21. Oktober um 14:00 UTC.
Dieser Beitrag erklärt, wie solche Zeitfenster entstehen und wie Sie Ihres verkürzen. Die genaue Datenfolge finden Sie in der PHP2Shell-Zeitlinie.
Das Zeitfenster zwischen Patch und Angriff in Phasen
Rund um eine Sicherheitslücke lassen sich mehrere Phasen unterscheiden. Bei PHP2Shell sahen sie so aus:
| Phase | Allgemein | Bei PHP2Shell |
|---|---|---|
| Vor Bekanntwerden | Lücke ist nur Entdeckern und Hersteller bekannt | Entwicklung der Korrektur unter Embargo |
| Erste Angriffe ohne Patch | Angreifer nutzen die Lücke, bevor ein Update existiert | laut Medienberichten erster Versuch am 17.10. |
| Vorankündigung | Hersteller kündigt Update an | 20.10., php.net kündigt das Release an |
| Patch verfügbar | Update und Sicherheitsmeldung erscheinen | 21.10., 14:00 UTC |
| Auswertung des Patches | Forscher und Angreifer analysieren die Änderungen | watchTowr hat CVE-2026-109618 nach eigenen Angaben nachgestellt |
| Breite Ausnutzung | automatisierte Kampagnen gegen ungepatchte Server | vom BSI erwartet; bestätigte erfolgreiche Angriffe in der Breite zunächst nicht bekannt |
| Ihr Patch | Update und Neustart auf Ihren Servern | individuell |
Die letzte Zeile ist die einzige, die Sie beeinflussen. Alles davor bestimmen andere.
Warum der Patch selbst den Druck erhöht
Ein Sicherheitsupdate schließt die Lücke, macht sie aber zugleich sichtbar. Quellcode-Änderungen bei Open-Source-Projekten wie PHP sind öffentlich. Wer die Unterschiede zwischen alter und neuer Version vergleicht, erfährt, an welcher Stelle der Fehler lag. Das ist kein Vorwurf an das PHP-Projekt, sondern der Normalfall offener Software und die Grundlage dafür, dass Distributionen Backports bauen können.
Für Betreiber folgt daraus: Mit jedem Tag nach dem Patch wächst die Zahl derer, die wissen, wie die Lücke funktioniert. Gleichzeitig sinkt die Zahl ungepatchter Server. Die verbleibenden werden damit zu den naheliegenden Zielen. Wie PHP Sicherheitsupdates im Rahmen seiner Versionspflege ausliefert, erklärt der Beitrag zum Release-Zyklus von PHP.
Wenn Ihr Server zwischen dem 17. Oktober und Ihrem Patch erreichbar war, gehört eine Prüfung auf Spuren dazu. Sichern Sie die Logs ab dem 20. Oktober, bevor sie durch Rotation verloren gehen.
Ihr eigenes Zeitfenster messen
Ihr persönliches Zeitfenster beginnt spätestens mit der Veröffentlichung der Patches und endet mit dem Neustart des letzten PHP-Prozesses. Halten Sie für jeden Server fest:
- Kenntnis: Wann hat jemand im Unternehmen von der Lücke erfahren?
- Verfügbarkeit: Wann stand das Paket Ihrer Distribution oder Ihres Hosters bereit?
- Installation: Wann wurde es eingespielt?
- Neustart: Wann liefen keine alten PHP-Prozesse mehr?
Gerade der Neustart wird oft vergessen. Ein installiertes Update wirkt erst, wenn die alten Prozesse beendet sind. Wie Sie das prüfen, beschreibt PHP-FPM und alle PHP-Prozesse neu starten. Ob noch Prozesse von vor dem Update laufen, zeigt ein Blick auf die Startzeiten:
# Startzeit aller PHP-Prozesse anzeigen
ps -eo pid,lstart,cmd | grep -E "php-fpm|php-cgi|lsphp" | grep -v grep
Liegt die Startzeit vor der Installation des Updates, ist das Fenster noch offen.
Warum Ihr Fenster vom Bezugsweg abhängt
Wie schnell Sie patchen können, hängt nicht nur von Ihnen ab, sondern auch davon, woher Ihr PHP kommt. Distributionen haben Backports laut Berichten teils noch am 21. Oktober ausgeliefert. Wer PHP aus einem Drittanbieter-Repository bezieht, ist auf dessen Tempo angewiesen. Wer Container nutzt, muss Images neu bauen und ausrollen, ein bloßes Update im laufenden Container reicht nicht. Und beim Shared Hosting bestimmt der Hoster den Zeitpunkt.
Kennen Sie den Bezugsweg jedes Servers, wissen Sie auch, an welcher Stelle Ihr Fenster am längsten offen bleibt. Genau dort lohnt sich Vorbereitung am meisten, etwa durch eine Absprache mit dem Hoster oder einen getesteten Ablauf für neue Container-Images.
So verkürzen Sie das Zeitfenster beim nächsten Mal
- Meldungen abonnieren: Sicherheitsmeldungen von php.net und Ihrer Distribution direkt empfangen, nicht erst über die Presse.
- Zuständigkeit festlegen: Für jeden Server eine verantwortliche Person mit Vertretung.
- Automatik nutzen, wo sie passt: Sicherheitsupdates aus der Distribution können automatisch eingespielt werden. Was dafür spricht und was dagegen, beschreibt Automatische Sicherheitsupdates.
- Neustart einplanen: Der Neustart der PHP-Dienste gehört fest in den Ablauf, nicht in die Nachbereitung.
- Notfallweg vorbereiten: Notseite und Entscheidung über eine vorübergehende Abschaltung, falls ein Update nicht sofort möglich ist.
- Nachweis führen: Zeitpunkte von Installation und Neustart dokumentieren, damit Sie Ihr Fenster später belegen können.
Ein dauerhafter Prozess, der diese Punkte bündelt, ist im Beitrag zum Patch-Management-Prozess beschrieben.
Wie hilft PHP SOS konkret?
- Patch und Neustart: Wir spielen das Update ein und stellen sicher, dass keine alten PHP-Prozesse mehr laufen.
- Zeitfenster belegen: Wir dokumentieren Installation und Neustart je Server mit Zeitpunkt.
- Spurenprüfung: Für die Zeit, in der Ihr Server offen war, sichern wir Logs und prüfen auf Auffälligkeiten.
- Prozess für die Zukunft: Wir richten mit Ihnen Meldewege, Zuständigkeiten und Update-Abläufe ein.
Mehr dazu unter PHP-Patch-Service.
Fazit
Bei PHP2Shell gab es keine Schonfrist. Das Zeitfenster zwischen Patch und Angriff ist bei kritischen Lücken heute oft null oder sogar negativ. Was Sie steuern können, ist Ihr eigenes Fenster: Es endet mit dem Neustart, und es lässt sich mit Vorbereitung von Tagen auf Stunden verkürzen.
Häufige Fragen
Wie viel Zeit bleibt nach einem Sicherheitsupdate bis zu Angriffen?
Eine feste Frist gibt es nicht. Bei PHP2Shell wurde laut Medienberichten ein erster Angriffsversuch schon am 17. Oktober beobachtet, also vier Tage vor den Patches. Bei kritischen Lücken in verbreiteter Software sollten Sie davon ausgehen, dass praktisch keine Schonfrist besteht.
Was ist ein Zero-Day?
Eine Lücke, die angegriffen wird, bevor ein Update verfügbar ist. Der Hersteller hatte gewissermaßen null Tage Zeit, sie zu beheben. Danach spricht man oft von einer bekannten oder N-Day-Lücke, für die es bereits einen Patch gibt.
Warum werden Angriffe nach einem Patch oft häufiger?
Mit dem Patch wird öffentlich, an welcher Stelle der Fehler lag. Sicherheitsforscher und Angreifer können die Änderungen auswerten. Zugleich bleiben viele Server noch Tage oder Wochen ungepatcht und damit lohnende Ziele.
Wann ist mein Server wirklich geschützt?
Wenn das Update installiert ist und alle PHP-Prozesse neu gestartet wurden. Neue Dateien allein wirken nicht, solange alte Prozesse im Speicher laufen. Das Ende Ihres persönlichen Zeitfensters ist also der Neustart, nicht der Download.