Fallbeispiel php2shell
Eine PHP-Lücke mit 9,2 von 10. Was in der Nacht danach passiert ist.
Am 21. Oktober 2026 veröffentlichte das PHP-Projekt Korrekturen für zwei Lücken, die zusammen das Ausführen fremden Codes ohne Anmeldung erlauben: CVE-2026-109618 und CVE-2026-109619, bekannt als php2shell, CVSS 9,2. Hier steht, wie es auf einem Server unter Sentinel ablief, was Sie selbst prüfen können und was Sentinel dabei nicht leistet.
Chronik
Vom Hinweis bis zum Protokoll, ohne dass jemand aufstand.
- 21. Okt.
PHP veröffentlicht die Korrekturen. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen beide Lücken. Beobachter melden Suchverkehr nach der Lücke schon vor dem Patch.
- 21. Okt., 16:07 Uhr
Ubuntu liefert die Pakete. Sicherheitshinweis USN-8948-1 mit korrigierten Paketen für Ubuntu 22.04, 24.04 und 26.04, für 22.04 als php8.1 in der Fassung 8.1.2-1ubuntu2.28.
- 22. Okt., 6:34 Uhr
Sentinel spielt das Update ein. Im Wartungsfenster eines angeschlossenen Servers mit Ubuntu 22.04, dort auf 6:30 Uhr gestellt, startet der Lauf „12 Sicherheitsupdates einspielen“: Prüfprofil, Paketstand festhalten, Sicherung der Konfiguration, Abbild der ganzen Maschine, dann die Sicherheitsupdates, darunter php8.1 8.1.2-1ubuntu2.28, dann dieselbe Prüfung noch einmal.
- 22. Okt., 6:37 Uhr
Lauf abgeschlossen. Drei Minuten, Ergebnis im Protokoll: erfolgreich. Jeder Schritt mit Befehl, Ausgabe, Dauer und Prüfsumme. Gut 14 Stunden nach dem Hinweis von Ubuntu war die Lücke auf diesem Server geschlossen.
Warum erst im Fenster? Auf dem Server tauchten die Pakete erst um 22:37 Uhr in den Paketlisten auf, sechseinhalb Stunden nach dem Hinweis von Ubuntu. Weil zugleich zwei gewöhnliche Updates anstanden, hat Sentinel alles zusammen als einen Lauf für das Wartungsfenster geplant, statt die Sicherheitsupdates allein sofort einzuspielen. Für sich genommen hätten sie kein Fenster gebraucht. Das Protokoll zeigt die stündliche Entscheidung „Außerhalb des Wartungsfensters“ ab 22:41 Uhr. Das ist inzwischen behoben: Sentinel trennt die Sicherheitsupdates ab und spielt sie sofort ein; die gewöhnlichen Updates warten auf das Fenster.
Noch ein Detail aus dem Protokoll. Die Website-Prüfung dieses Servers stand schon vor dem Lauf auf Rot, weil die Seite nicht binnen 30 Sekunden antwortete. Sentinel hat trotzdem gewartet und als Fehlschlag nur gezählt, was danach neu rot gewesen wäre. Es war nichts, und die alte Störung blieb als solche gemeldet.
Zum Vergleich der Weg von Hand: am Morgen aus den Nachrichten erfahren, Versionen prüfen, Fenster planen, einspielen, hoffen, dass die Seite danach noch läuft. Bei zehn Servern ein Vormittag. Bei Servern, die niemand regelmäßig wartet, bleibt die Lücke offen, bis jemand hineinkommt.
Zeiten in MESZ aus dem Sentinel-Protokoll des Servers und aus dem Ubuntu-Sicherheitshinweis. Der Server ist ein Kundensystem; Name und Adresse nennen wir nicht.
Selbst prüfen
Zwei Befehle, zwei Minuten.
Auf Ubuntu und Debian zählt nicht die PHP-Versionsnummer allein, sondern ob das Paket die Korrektur enthält. Die Distributionen tragen Korrekturen in ihre Paketfassung ein, ohne die PHP-Version zu erhöhen. Der Paket-Changelog verrät es:
dpkg -l 'php*' | grep ^ii
apt-get changelog php8.1 | grep -m1 CVE-2026-109619Erscheint eine Zeile mit der CVE-Nummer, ist das installierte Paket korrigiert. Auf Ubuntu 24.04 heißt das Paket php8.3, auf 26.04 php8.5; auf Debian 12 php8.2, auf Debian 13 php8.4. Welche Paketfassungen korrigiert sind, nennt der Sicherheitshinweis USN-8948-1.
Wenn Sie nicht sofort einspielen können
Das PHP-Projekt nennt als Übergang das Abschalten des Upload-Fortschritts in der php.ini, gefolgt von einem Neustart von PHP-FPM oder dem Webserver:
session.upload_progress.enabled = 0Das schließt den bekannten Weg über CVE-2026-109619, nicht jede Variante. Einspielen bleibt Pflicht.
Was Sentinel tut
Nicht schneller als Ubuntu. Aber schneller als der Montag.
Sentinel findet keine Lücken, die niemand kennt. Es sorgt dafür, dass bekannte Lücken auf Ihren Servern nicht offen bleiben, bis jemand Zeit hat.
- Prüfung alle zehn Minuten.Offene Sicherheitsupdates je Server, abgeglichen mit den Ubuntu-Sicherheitshinweisen und dem CISA-Katalog aktiv ausgenutzter Lücken. Das Lagebild sagt, welche Server betroffen sind und ob ein Fix da ist.
- Einspielen, sobald die Distribution liefert.In der Regel binnen einer Stunde, auch nachts, ohne auf ein Wartungsfenster zu warten. Stehen zugleich gewöhnliche Updates an, spielt Sentinel die Sicherheitsupdates sofort ein; die übrigen warten auf das Fenster. Erst Prüfprofil, dann Paketstand festhalten, dann einspielen, dann dieselbe Prüfung noch einmal.
- Rückweg.Steht die Website nach dem Update auf Rot, startet Sentinel stehende Dienste neu und rollt sonst Pakete und Konfiguration zurück. Gelingt das nicht, hält es die Automatik des Servers an und alarmiert.
- Protokoll.Jeder Schritt mit Prüfsummenkette. Wenn ein Kunde oder Prüfer fragt, wann php2shell auf Ihren Servern geschlossen war, steht die Antwort da, mit Uhrzeit.
Grenzen
Was ein Update nicht heilt.
War ein Server vor dem Update schon übernommen, ändert das Update daran nichts. Sentinel erkennt auf dem Server fremde SSH-Schlüssel, neue Konten, neue Zeitpläne, neue Ports und geänderte Systemdateien und legt dazu eine Akte an. Angriffe auf die Webanwendung selbst, etwa über diese PHP-Lücke, sieht es nicht. Dafür braucht es eine Web Application Firewall oder eine Analyse durch Menschen.
Für den Verdacht auf einen gelungenen Angriff: Sicherheitsanalysen und Penetrationstests von LimeByte, dem Team hinter Sentinel.
Quellen: Ubuntu USN-8948-1 (21.10.2026, 14:07 UTC); Sansec: PHP2Shell; ma.ttias.be: early mitigation steps; ellio.tech: what we observed. Zeiten des Laufs aus dem Sentinel-Protokoll.