Kurz gesagt: Nach PHP2Shell sind weitere Meldungen zu PHP wahrscheinlich, weil schon zwei Tage nach dem Patch ein dritter Hinweis kam, ein vollständiges Advisory noch aussteht und Distributionen ihre Pakete gestaffelt nachliefern. Wer jetzt einen festen Ablauf für Beobachtung, Bewertung, Update und Neustart einrichtet, reagiert auf die nächste neue PHP-Sicherheitslücke in Stunden statt in Tagen.
Der Patch war nicht das Ende der Geschichte
Am 21. Oktober 2026 schloss das PHP-Projekt die beiden kritischen Lücken CVE-2026-109618 und CVE-2026-109619 mit den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Viele Verantwortliche haben danach einen Haken gesetzt. Zwei Tage später, am 23. Oktober, folgte jedoch ein weiterer Hinweis von php.net zu CVE-2026-115560.
Dieser dritte Hinweis betrifft nur eine ungewöhnliche Session-Konfiguration. Er zeigt aber ein Muster, das man von großen Sicherheitsfällen kennt: Wenn eine Komponente plötzlich im Rampenlicht steht, sehen viele Fachleute gleichzeitig genauer hin. Ob daraus weitere Lücken entstehen, weiß heute niemand. Wahrscheinlich ist aber, dass die Nachrichtenlage nicht abreißt.
Für Sie als Betreiber heißt das: Planen Sie Folgemeldungen ein, statt von jeder überrascht zu werden. Den bisherigen Ablauf der Ereignisse fasst unsere PHP2Shell-Chronologie zusammen.
Warum weitere Meldungen wahrscheinlich sind
Die folgende Einschätzung beruht auf öffentlich bekannten Fakten. Sie ist keine Vorhersage konkreter Lücken.
- Ein Advisory steht noch aus. php.net behandelt CVE-2026-115560 im regulären Release-Zyklus und hat angekündigt, das vollständige Advisory mit dem nächsten Release zu veröffentlichen. Bis dahin gilt
session.upload_progress.enabled=0als Abhilfe. - Die Details waren früh öffentlich. Laut mehreren Berichten wurden Einzelheiten vor Ablauf des Embargos bekannt. Laut Berichten hat watchTowr CVE-2026-109618 nach eigenen Angaben nachgestellt. Solche Arbeiten führen häufig zu Folgefragen an benachbarten Codestellen.
- Distributionen liefern gestaffelt. Ubuntu hat am 21. Oktober mit USN-8948-1 die aktuellen Releases versorgt und mit USN-8948-2 Korrekturen für 14.04 bis 20.04 über Ubuntu Pro nachgereicht. Red Hat schrieb in seinem Bulletin, einige Updates seien verfügbar, weitere in Arbeit.
- Die Entwicklungsversion ist betroffen. Laut php.net enthält auch PHP 8.6.0 RC4 die Korrekturen. Wer Vorabversionen testet, muss auch diese Umgebungen nachziehen.
- Altversionen bleiben offen. Für PHP 8.1 und älter gibt es nur minimale Quell-Backports. Jeder Anbieter, der solche Versionen ausliefert, meldet seinen Stand eigenständig und zu eigenen Zeitpunkten.
Wie eine neue PHP-Sicherheitslücke Sie erreicht
Meldungen kommen auf unterschiedlichen Wegen und mit unterschiedlicher Verlässlichkeit. Die Reihenfolge ist fast immer gleich: zuerst das PHP-Projekt, dann Distributionen und Hoster, danach Behörden und Medien.
| Quelle | Was Sie dort erfahren | Wie verlässlich |
|---|---|---|
| php.net | Betroffene Zweige, behobene Versionen, Übergangsmaßnahmen | Primärquelle |
| Ubuntu, Debian, Red Hat | Paketstände je Release, Zeitpunkt der Auslieferung | Primärquelle für Ihr System |
| Hoster und Panel-Anbieter | Stand der eigenen PHP-Builds | Nur verbindlich, wenn schriftlich |
| BSI, CERT-Bund | Lagebewertung, Warnstufe, Empfehlungen | Behördliche Einordnung |
| Fachpresse und Sicherheitsfirmen | Angriffsbeobachtungen, Zahlen, Hintergründe | Hilfreich, als Bericht kennzeichnen |
Wichtig ist der Unterschied zwischen „es gibt einen Patch“ und „mein System hat den Patch“. Die erste Aussage steht auf php.net. Die zweite müssen Sie für jeden Server selbst belegen.
Abonnieren Sie die Meldungen von php.net und Ihrer Distribution per RSS oder E-Mail-Liste und leiten Sie sie in ein gemeinsames Postfach oder einen Kanal, den mehr als eine Person liest. Urlaub und Krankheit sind die häufigsten Gründe für verspätete Updates.
Was Sie vor der nächsten Meldung vorbereiten sollten
Die Erfahrung aus PHP2Shell zeigt, wo Zeit verloren geht: beim Suchen nach Servern, beim Klären von Zuständigkeiten und beim vergessenen Neustart. All das lässt sich vorher erledigen.
- Inventar: Eine Liste aller Server und Websites mit PHP-Zweig, Betriebsart (PHP-FPM, mod_php, LiteSpeed) und Paketquelle. Ohne diese Liste beginnt jede Meldung mit Suchen. Wie das gelingt, beschreibt der Beitrag Inventar aller Websites und Server.
- Zuständigkeit: Für jedes System steht fest, wer patcht, wer neu startet und wer freigibt. Bei Hostern und Agenturen gehört das in den Vertrag.
- Bewertungsraster: Drei Fragen genügen für die erste Einordnung. Ist unser Zweig betroffen? Nutzen wir die betroffene Funktion oder Betriebsart? Gibt es einen Patch oder nur Übergangsmaßnahmen?
- Testweg: Eine Staging-Umgebung, in der ein PHP-Update in kurzer Zeit geprüft werden kann.
- Nachweis: Ein festes Format, in dem Paketstand, Changelog-Treffer und Neustartzeit festgehalten werden.
Wie ein solcher Ablauf als Routine statt als Feuerwehreinsatz funktioniert, steht unter Patch-Management als Prozess. Hintergrund zum Umgang des PHP-Projekts mit Lücken liefert die Seite Wie das PHP-Projekt Sicherheitslücken behandelt.
Die eigene Konfiguration als Frühwarnsystem
Ein Teil der Folgemeldungen betrifft nur bestimmte Einstellungen. CVE-2026-115560 ist dafür ein Beispiel: php.net nennt als Voraussetzung, dass eine Anwendung den Session-Serializer zur Laufzeit umstellt, während Upload-Progress aktiv ist. Anwendungen, die das nie tun, sind laut php.net nicht betroffen.
Wer seine wirksame Konfiguration kennt, kann solche Meldungen schneller einordnen. Halten Sie deshalb für jeden Zweig fest, welche Werte serverseitig gesetzt sind und welche Anwendungen sie überschreiben dürfen. Ein einfacher Abgleich der aktiven Einstellungen hilft bereits:
# Wirksame Werte der Kommandozeile (die Web-Konfiguration kann abweichen)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Gesetzte Werte in den FPM-Pools (Pfad je Distribution verschieden)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
Die Kommandozeile zeigt nicht zwingend, was im Webkontext gilt. Für Klarheit sorgen die Pool- oder VirtualHost-Konfiguration und, kurzzeitig und geschützt, eine phpinfo-Seite.
Ein weiterer Vorteil: Wer weiß, welche Übergangswerte noch aus der PHP2Shell-Woche gesetzt sind, kann sie nach dem nächsten regulären Release bewusst prüfen. Manche Einstellungen, etwa abgeschalteter Upload-Progress, können dauerhaft sinnvoll bleiben. Andere, wie sehr knappe Upload-Grenzen, sollten Sie nach Rücksprache mit den Fachabteilungen wieder an den echten Bedarf anpassen.
Wie hilft PHP SOS konkret?
- Wir verfolgen die Meldungen von php.net, Distributionen und BSI und bewerten neue Hinweise für Ihre konkreten Systeme.
- Wir erstellen mit Ihnen das Inventar aller PHP-Installationen und legen Zuständigkeiten je Server fest.
- Im Rahmen eines Security-Wartungsvertrags spielen wir Updates ein, starten alle Prozesse neu und dokumentieren den Stand.
- Bei Meldungen ohne Patch setzen wir Übergangsmaßnahmen nicht überschreibbar und prüfen sie nach.
Häufige Fragen
Gibt es nach PHP2Shell schon eine neue PHP-Sicherheitslücke?
Am 23. Oktober 2026 hat php.net einen Hinweis zu CVE-2026-115560 veröffentlicht. Codeausführung ist danach nur bei einer ungewöhnlichen Session-Konfiguration möglich. Ein vollständiges Advisory soll mit dem nächsten regulären Release folgen.
Muss ich nach jeder neuen Meldung sofort handeln?
Nicht jede Meldung verlangt dieselbe Eile. Entscheidend sind Schweregrad, Betroffenheit Ihrer Konfiguration und die Frage, ob ein Patch verfügbar ist. Ein festgelegter Ablauf hilft, das in Minuten statt in Tagen zu bewerten.
Wo erfahre ich zuerst von neuen PHP-Lücken?
Primärquellen sind die Meldungen auf php.net und die Sicherheitshinweise Ihrer Distribution, etwa Ubuntu Security Notices, der Debian Security Tracker oder Red Hat. Das BSI informiert über Warnmeldungen. Medienberichte sind hilfreich, aber oft später und weniger genau.
Warum melden Distributionen manchmal Tage später als php.net?
Distributionen müssen die Korrektur in ihre eigenen Pakete übernehmen, bauen und testen. Für ältere Releases kann das länger dauern oder nur über Zusatzangebote erfolgen. Deshalb lohnt es, beide Quellen getrennt zu verfolgen.