Nur zwei Tage nach den kritischen PHP2Shell-Sicherheitsupdates weist das PHP-Projekt auf eine weitere, davon getrennte RCE-Konstellation hin: CVE-2026-115560. Die gute Nachricht ist, dass sie laut offizieller Mitteilung nur unter einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode auftreten kann. Die wichtige Nachricht für Betriebsteams: Bis zum nächsten regulären PHP-Bugfix-Release soll session.upload_progress.enabled=0 gesetzt werden.

Das ist kein Anlass für hektische Änderungen ohne Prüfung. Es ist aber ein konkreter Auftrag, die wirksame PHP-Konfiguration der produktiven Webanwendungen zu kontrollieren. Wer die Maßnahme für die vorherige PHP2Shell-Lücke bereits umgesetzt hat, soll sie beibehalten; für die neue Warnung ist dann keine weitere Sofortaktion nötig.

Wichtige Punkte auf einen Blick
  • PHP empfiehlt als Schutzmaßnahme bis zum nächsten regulären Bugfix-Release session.upload_progress.enabled=0.
  • Gefährdet ist nicht jede PHP-Anwendung: Mehrere konkrete Konfigurations- und Code-Bedingungen müssen gleichzeitig erfüllt sein.
  • Die Warnung ist von PHP2Shell getrennt. Die am 21. Oktober veröffentlichten Patches gegen CVE-2026-109618 und CVE-2026-109619 lösen diese neue Konstellation nicht automatisch ab.
  • Prüfen Sie die Runtime, nicht nur den Quellcode: Entscheidend sind die Einstellungen des produktiven PHP-FPM-, Apache-, Container- oder Hosting-Prozesses.
  • Testen Sie Upload-Abläufe nach der Änderung. Anwendungen verlieren durch das Abschalten die Upload-Fortschrittsfunktion, nicht aber den normalen Datei-Upload selbst.

Die Lage am 23. Oktober: eine gezielte Warnung statt eines Notfall-Patches

Das PHP-Projekt veröffentlichte am 23. Oktober eine kurze Informationsmeldung zu CVE-2026-115560. Darin beschreibt es einen unwahrscheinlichen Pfad zu Remote Code Execution, also zur Ausführung von Programmcode auf einem Webserver. Weil diese Konstellation nach Einschätzung des Projekts selten ist, erfolgt der Fix im regulären Release-Zyklus. Bis dahin ist die empfohlene Konfigurationsmaßnahme klar und einfach: Session-Upload-Fortschritt deaktivieren.

Wichtig ist die Einordnung: Die Warnung betrifft einen anderen Pfad als die am 21. Oktober veröffentlichten PHP2Shell-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Für diese beiden Lücken stehen Sicherheitsupdates bereit. CVE-2026-115560 wird dagegen erst mit einem kommenden regulären Release vollständig adressiert. Fachberichte meldeten zum Zeitpunkt der Veröffentlichung keine bekannte Ausnutzung dieser neuen CVE; das ersetzt jedoch keine eigene Konfigurationsprüfung.

Wann eine Anwendung betroffen sein kann

Die Warnung lässt sich präzise eingrenzen. Ein Risiko entsteht laut PHP nur dann, wenn mehrere Bedingungen zusammenkommen. Genau deshalb sollten Verantwortliche die Konfiguration und den Anwendungscode zielgerichtet prüfen, statt pauschal von einer vollständigen Betroffenheit auszugehen.

  • In der PHP-Konfiguration ist session.serialize_handler auf php_binary oder php_serialize gesetzt.
  • Der Anwendungscode stellt diese Einstellung vor session_start() per ini_set() zur Laufzeit auf php um.
  • Session-Upload-Fortschritt bleibt dabei aktiviert.

Fehlt eine dieser Voraussetzungen, beschreibt die aktuelle PHP-Mitteilung diesen speziellen Angriffsweg nicht als gegeben. Anwendungen, die den Serialisierungs-Handler nicht zur Laufzeit umstellen, können die Fortschrittsfunktion laut PHP grundsätzlich aktiviert lassen. Für die betrieblich einfache und vom Hersteller empfohlene Zwischenlösung bleibt das Deaktivieren dennoch der sichere Standard, bis ein Bugfix vorliegt.

Die sofortige Übergangsmaßnahme: Upload-Fortschritt abschalten

Setzen Sie in der wirksamen PHP-Konfiguration die Einstellung session.upload_progress.enabled=0. Entscheidend ist das Wort „wirksam“: Eine Änderung in einer lokalen php.ini schützt den Server nicht, wenn die öffentlich erreichbare Anwendung über einen anderen PHP-FPM-Pool, ein separates Container-Image oder eine vom Hosting bereitgestellte Runtime läuft.

Das Abschalten deaktiviert die PHP-Funktion, mit der Anwendungen den Fortschritt eines Dateiuploads innerhalb einer Session abfragen können. Der Datei-Upload an sich wird dadurch nicht grundsätzlich abgeschaltet. Dennoch sollte ein Team nach der Änderung die eigenen Upload-Formulare, eventuell vorhandene Fortschrittsanzeigen und die zugehörigen Hintergrundprozesse testen. Bei verwaltetem Hosting ist eine kurze, eindeutige Anfrage sinnvoll: Ist die Einstellung für die produktive PHP-Runtime wirksam gesetzt und wurden die Worker neu geladen?

Bereits für PHP2Shell gehandelt?

PHP weist ausdrücklich darauf hin, dass die gleiche Einstellung bereits als Minderung für CVE-2026-109619 genannt wurde. Wurde sie damals gesetzt und nicht wieder zurückgenommen, ist für CVE-2026-115560 keine zusätzliche Sofortmaßnahme erforderlich.

Konfiguration und Code richtig prüfen

Beginnen Sie bei der Laufzeitumgebung. Auf einem verwalteten Server oder im Container kann ein Blick auf die für die Anwendung aktive PHP-Info beziehungsweise die Pool-Konfiguration zeigen, welcher Wert für session.serialize_handler und session.upload_progress.enabled tatsächlich gilt. Die Ausgabe von php -i auf der Kommandozeile ist nur ein erster Hinweis; sie kann von der Konfiguration des Webservers abweichen.

Prüfen Sie anschließend den Anwendungscode und eingebundene Bibliotheken auf Aufrufe von ini_set('session.serialize_handler', ...). Entscheidend ist nicht nur, dass die Einstellung geändert wird, sondern welcher Ausgangswert in der Serverkonfiguration liegt, auf welchen Wert der Code wechselt und ob dies vor session_start() geschieht. Dokumentieren Sie das Ergebnis pro produktiver Anwendung, statt eine Annahme von einer Instanz auf alle anderen zu übertragen.

In einer Infrastruktur mit mehreren Instanzen gehören auch Staging-Systeme, alte Subdomains, separate Admin-Oberflächen, Cron-Container und Disaster-Recovery-Umgebungen in die Bestandsaufnahme. Die Cyber Security Agency of Singapore empfiehlt im Zusammenhang mit PHP2Shell ausdrücklich, PHP-Installationen auch dann zu suchen, wenn die Hauptwebsite selbst nicht offensichtlich PHP nutzt. Dieses Vorgehen ist für die neue Warnung ebenso sinnvoll.

Änderung kontrolliert ausrollen statt nur eine Datei zu editieren

Halten Sie den Eingriff klein und nachvollziehbar: Konfigurationsdatei oder Deployment-Vorlage anpassen, Änderung durch die passende PHP-Runtime laden lassen und danach die Funktion prüfen. Bei PHP-FPM gehört dazu üblicherweise ein kontrolliertes Neuladen oder Neustarten der Worker. In Container-Plattformen muss das Basis- oder Konfigurations-Image neu gebaut und ausgerollt werden. Ein einzelner aktualisierter Git-Commit ändert noch keinen laufenden Prozess.

Verifizieren Sie danach den effektiven Wert auf mindestens einer Instanz jedes Deployment-Typs und testen Sie einen repräsentativen Upload. Achten Sie zusätzlich auf Fehlerprotokolle, ungewöhnliche Abbrüche und auffällige Session-Fehler. So wird aus einer kurzfristigen Mitigation ein kontrollierter Sicherheitsprozess mit nachweisbarem Ergebnis.

Was jetzt Priorität hat

Zuerst sollten Teams die kritischen PHP2Shell-Updates aus dem Hinweis vom 21. Oktober sicherstellen. Diese bekannten Lücken betreffen alle PHP-Versionen und sollten insbesondere auf öffentlich erreichbaren Systemen ohne Verzögerung auf den vom Hersteller empfohlenen Patchstand gebracht werden. Danach oder parallel folgt die hier beschriebene Konfigurationsmaßnahme für CVE-2026-115560.

Danach lohnt sich ein fester Wiedervorlagepunkt: Sobald PHP den regulären Bugfix-Release und die vollständige Sicherheitsberatung veröffentlicht, prüfen Sie Release Notes, Paketstand des Betriebssystems oder Hosting-Anbieters sowie die weiterhin benötigte Konfiguration. Bis dahin gilt: Die Übergangsmaßnahme nicht versehentlich in einer späteren Konfigurationsänderung zurückdrehen.

Häufige Fragen zu CVE-2026-115560

Ist jede PHP-Website automatisch von CVE-2026-115560 betroffen?

Nein. Laut PHP müssen eine bestimmte Konfiguration des Session-Serialisierungs-Handlers, eine Änderung dieses Werts per ini_set() vor session_start() und aktivierter Session-Upload-Fortschritt gemeinsam vorliegen. Unabhängig davon empfiehlt PHP das vorübergehende Deaktivieren der Fortschrittsfunktion als vollständige Minderung dieses Pfads.

Reichen die PHP2Shell-Sicherheitsupdates vom 21. Oktober aus?

Die Sicherheitsupdates behandeln CVE-2026-109618 und CVE-2026-109619. Für CVE-2026-115560 empfiehlt PHP bis zum nächsten regulären Bugfix-Release zusätzlich die Konfiguration session.upload_progress.enabled=0. Beide Maßnahmen sollten getrennt dokumentiert und verifiziert werden.

Was verändert sich durch das Abschalten von Session-Upload-Fortschritt?

Die serverseitige PHP-Funktion zur Session-basierten Fortschrittsverfolgung von Datei-Uploads steht der Anwendung dann nicht mehr zur Verfügung. Normale Uploads können weiterhin funktionieren, doch individuelle Fortschrittsanzeigen oder darauf aufbauende Funktionen sollten nach der Änderung getestet werden.

Wie lange muss die Einstellung deaktiviert bleiben?

Bis zum nächsten regulären PHP-Bugfix-Release und der dazu angekündigten vollständigen Beratung. Prüfen Sie danach die offizielle PHP-Mitteilung und den konkreten Paketstand Ihrer Runtime, bevor Sie eine Konfigurationsänderung wieder zurücknehmen.

Quellen & Weiterführende Nachweise