Erneut PHP-Lücke mit Remote-Code-Execution : Eine seltene Session-Konfiguration auf Webservern birgt Risiken – eine Einstellung schafft vorläufig Abhilfe

Die neue, unter CVE-2026-115560 geführte Schwachstelle ermöglicht unter bestimmten Voraussetzungen eine entfernte Codeausführung (Remote Code Execution, RCE). Betroffen sind nur Anwendungen mit einer bestimmten Kombination aus Einstellungen und Programmabläufen. Die neue Lücke besteht zusätzlich zu den beiden bereits behobenen PHP2Shell-Lücken: Die am 21. Oktober 2026 veröffentlichten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bieten dagegen keinen Schutz!

Nach Einschätzung des PHP-Projekts kommt die angreifbare Kombination in der Praxis allerdings selten vor. Die Entwickler wollen die Lücke deshalb mit dem nächsten regulären Wartungsupdate schließen; ein weiteres Notfallupdate ist vorerst nicht geplant.

Welche Konfiguration betroffen ist

Der neue Angriffsweg setzt voraus, dass Konfiguration und Anwendungscode auf eine bestimmte Weise zusammenspielen. Sämtliche folgenden Bedingungen müssen erfüllt sein:

• in der Konfiguration steht session.serialize_handler auf php_binary oder php_serialize
• die Anwendung ändert diesen Wert während der Ausführung mit ini_set() auf php
• diese Änderung erfolgt vor dem Aufruf von session_start()
• die Funktion Session-Upload-Progress ist weiterhin aktiviert

Der Serialisierungshandler bestimmt, in welchem Format PHP Sitzungsdaten speichert und wieder einliest. Die genannten Werte bezeichnen unterschiedliche Formate. Hier ist der Wechsel zwischen diesen Formaten vor dem Start der Sitzung Teil der problematischen Konstellation.

Die standardmäßig aktivierte Funktion „Session Upload Progress“ zeigt einer Anwendung, wie weit das Hochladen einer Datei fortgeschritten ist. PHP speichert die dafür benötigten Informationen in den Sitzungsdaten. Ändert die Anwendung während ihrer Ausführung nicht das Speicherformat dieser Daten, ist sie laut dem PHP-Sicherheitshinweis vom 23. Oktober über diesen Angriffsweg nicht gefährdet. Die Funktion kann dann eingeschaltet bleiben.

Welche Einstellung vorläufig schützt

Das PHP-Projekt empfiehlt, bis zum nächsten regulären Fehlerbehebungsrelease session.upload_progress.enabled=0 zu setzen. Damit wird die sitzungsbasierte Erfassung des Upload-Fortschritts abgeschaltet.

Betreiber sollten die Einstellung in der PHP-Konfiguration ändern, die ihre Webanwendung tatsächlich verwendet. Anschließend sollten sie prüfen, ob die Funktion abgeschaltet ist. Nutzt die Anwendung diese Funktion für eine Upload-Fortschrittsanzeige, steht diese vorübergehend nicht mehr zur Verfügung. Das Hochladen von Dateien bleibt weiterhin möglich.

Die Maßnahme wurde bereits im Sicherheitshinweis zu CVE-2026-109619 empfohlen. Wer sie damals umgesetzt und die Funktion seitdem ausgeschaltet gelassen hat, muss für den neuen Angriffsweg nichts weiter ändern. Die Sicherheitsupdates gegen die beiden früheren PHP2Shell-Lücken müssen aber trotzdem installiert werden.

Was über die neue Lücke noch offen ist

Bis zum 23. Oktober hat das PHP-Projekt noch nicht veröffentlicht, welche Versionen betroffen sind und welche Updates die Lücke schließen werden. Auch eine Bewertung der Schwere und eine ausführliche technische Erklärung fehlen bislang. Unklar ist zudem, ob CVE-2026-115560 und die frühere Lücke CVE-2026-109619 auf denselben Fehler zurückgehen.

Da mehrere ungewöhnliche Bedingungen zusammenkommen müssen, sind nur bestimmte Anwendungen gefährdet. Betreiber sollten deshalb prüfen, wie ihre Anwendung Sitzungsdaten verarbeitet und welche PHP-Einstellungen sie verwendet. Erst danach lässt sich beurteilen, ob sie betroffen ist.

Aktuelle Attacken betreffen bislang die früheren PHP2Shell-Lücken

Für CVE-2026-115560 wurden bislang keine Angriffe gemeldet. Beobachtete Aktivitäten richten sich gegen CVE-2026-109618 und CVE-2026-109619, die durch die Notfallupdates vom 21. Oktober geschlossen wurden.

Amazon bemerkte bereits am 17. Oktober einen Versuch, die beiden früheren PHP2Shell-Lücken auszunutzen – vier Tage bevor sie öffentlich bekannt wurden. Erfasst wurde der Versuch von einem Honeypot, einem Ködersystem, das Angriffe anlockt und aufzeichnet. Nach der Veröffentlichung nahm die Aktivität stark zu: Cloudflare zählte innerhalb von 45 Minuten Zehntausende Angriffsversuche, bis zum frühen 22. Oktober waren es Millionen.

Laut Sophos und Arctic Wolf wollten Angreifer eine Variante der Schadsoftware Mirai auf den Servern installieren. Damit könnten sie die Systeme in ein Botnetz aufnehmen und aus der Ferne für weitere Angriffe steuern. Eine erfolgreiche Codeausführung wurde dabei bislang jedoch nicht bestätigt. Previdian, Wordfence und weitere Beobachter meldeten vor allem automatisierte Suchläufe und Tests auf verwundbare Server. Die Lücken zuverlässig auszunutzen, erwies sich bisher als schwieriger als erwartet.

Für Betreiber ergeben sich daraus zwei Aufgaben: die früheren PHP2Shell-Lücken durch Updates schließen und zusätzlich prüfen, ob ihre Anwendung die Voraussetzungen für CVE-2026-115560 erfüllt. Das Abschalten von Session Upload Progress unterbindet den neu beschriebenen Angriffsweg bis zur vorgesehenen Korrektur.