CVE-2026-115560: Neue PHP-Session-Lücke prüfen und abstellen

Am 23.10.2026 hat das PHP-Projekt eine weitere Schwachstelle gemeldet, CVE-2026-115560. Sie kann im Erfolgsfall zu Codeausführung auf dem Server führen, aber nur bei einer ungewöhnlichen Kombination aus Konfiguration und Anwendungscode. Ein Notfall-Update gibt es deshalb nicht. Bis zum nächsten regulären Release empfiehlt PHP, die Funktion Session Upload Progress abzuschalten. Dieser Ratgeber zeigt, wie Sie prüfen, ob Ihre Anwendung betroffen ist, und wie Sie die Einstellung so setzen, dass sie tatsächlich wirkt.

Stand: 23.10.2026, 16:12 MESZ. PHP hat das vollständige Advisory für CVE-2026-115560 noch nicht veröffentlicht, und bei der CVE-Vergabestelle gibt es noch keinen öffentlichen Eintrag zu CVE-2026-115560. Wir ergänzen den Artikel, sobald beides vorliegt.

Was ist CVE-2026-115560?

CVE-2026-115560 ist eine Lücke in der Session-Verarbeitung von PHP. Im informativen Hinweis auf php.net spricht das PHP-Projekt von einem unwahrscheinlichen Weg zu Remote Code Execution. Gemeint ist, dass ein Angreifer ohne Zugang eigenen Code auf dem Server ausführt. Die Bedingungen dafür sind aber eng, PHP behandelt die Lücke deshalb im normalen Release-Zyklus. Die PHP Foundation auf X fasst es so zusammen: Betroffen sind nur Anwendungen mit einem anderen Serialize-Handler als dem Standard, die zur Laufzeit auf php umstellen.

Mit PHP2Shell teilt die Lücke nur die Funktion, über die sie läuft. Es ist eine eigene Schwachstelle. Die Updates vom 21.10.2026 auf 8.2.35, 8.3.36, 8.4.27 und 8.5.12 schließen sie laut The Hacker News nicht. Ob sie dieselbe Ursache hat wie CVE-2026-109619, hat PHP nicht gesagt. Auch betroffene Versionen, eine CVSS-Bewertung und die Namen der Finder fehlen bisher. Was hinter PHP2Shell selbst steckt, erklärt der Ratgeber PHP2Shell einfach erklärt.

Wann ist eine Anwendung betroffen?

Nur wenn drei Bedingungen gleichzeitig zutreffen. PHP nennt sie so:

1. In der PHP-Konfiguration steht session.serialize_handler auf php_binary oder php_serialize.
2. Die Anwendung stellt diesen Wert zur Laufzeit mit ini_set() auf php um, bevor sie session_start() aufruft.
3. session.upload_progress.enabled ist eingeschaltet. Das ist der Standard.

Der Standardwert für session.serialize_handler ist laut PHP-Handbuch php. Eine Installation mit Standardwerten erfüllt die erste Bedingung also nicht. Anwendungen, die den Handler zur Laufzeit nie ändern, dürfen Upload Progress laut PHP eingeschaltet lassen.

Die Umstellung muss nicht in Ihrem eigenen Code stehen. Auch eine Bibliothek im Ordner vendor/ oder ein Plugin kann ini_set() aufrufen. Durchsuchen Sie deshalb den gesamten Code, den der Server ausführt, nicht nur Ihre eigenen Dateien.

WordPress selbst nutzt keine PHP-Sessions, Laravel verwaltet Sessions ohne die native Session-Funktion von PHP. Für den Kern dieser beiden Systeme ist die Kombination deshalb unwahrscheinlich. Plugins, Erweiterungen und ältere Eigenentwicklungen können trotzdem native Sessions mit eigenem Handler starten. Betreiben Sie WordPress, prüfen Sie den Plugin-Ordner. Das gehört ohnehin zu einer regelmäßigen WordPress-Wartung.

Warum der Wechsel des Handlers ein Risiko ist

PHP hat die technische Ursache noch nicht veröffentlicht. Die drei Bedingungen passen aber zu einem bekannten Muster. Die folgende Erklärung ist unsere Einordnung auf Basis der dokumentierten Session-Formate, nicht die Beschreibung des PHP-Projekts.

Der Serialize-Handler legt fest, in welchem Format PHP die Session speichert. Der Handler php schreibt jeden Eintrag als Name, senkrechten Strich und Wert. Der Handler php_serialize schreibt die ganze Session als ein Array mit serialize(). Liest PHP eine Session mit einem anderen Handler, als sie geschrieben wurde, kann ein senkrechter Strich mitten in einem Text als Trennzeichen gelten.

Upload Progress schreibt während eines Datei-Uploads den Fortschritt in die Session, laut PHP-Handbuch inklusive des Dateinamens. Das passiert, bevor Ihr Skript startet, also mit dem Handler aus der Konfiguration. Den Dateinamen bestimmt der Absender des Uploads. Stellt die Anwendung danach auf php um und liest die Session, kann ein präparierter Dateiname als eigener Session-Eintrag gelesen werden. PHP erzeugt dann womöglich ein Objekt nach Wahl des Angreifers. Ob daraus Codeausführung wird, hängt von den Klassen ab, die in der Anwendung geladen sind.

So prüfen Sie Ihre Anwendung

Die Prüfung dauert für eine Anwendung meist wenige Minuten. Sie brauchen Zugriff auf den Code und die PHP-Konfiguration. Bei Shared Hosting erledigen Sie Schritt 1 per SFTP-Download und fragen für Schritt 2 den Hoster.

Schritt 1: Code nach einer Umstellung des Handlers durchsuchen

# Passen Sie den Pfad an das Verzeichnis Ihrer Anwendung an
grep -rn "serialize_handler" /var/www/ --include=*.php --include=.user.ini

Kein Treffer bedeutet, dass die Anwendung den Handler nicht umstellt. Ein Treffer mit ini_set() und dem Wert php ist ein Kandidat für die Lücke. PHP nennt nur ini_set(). Bei PHP-FPM wirkt eine .user.ini laut PHP-Advisory vom 21.10.2026 aber ebenfalls erst nach der Verarbeitung des Uploads. Werten Sie eine Umstellung dort deshalb vorsichtshalber genauso.

Schritt 2: Konfiguration so prüfen, wie der Webserver sie sieht

Die Kommandozeile mit php -i liest oft eine andere php.ini als PHP-FPM oder Apache. Verlässlich ist nur ein Wert, den der Webserver selbst ausgibt. Legen Sie dafür kurz eine Datei mit zufälligem Namen im Web-Verzeichnis an:

<?php
// Temporäre Prüfdatei, direkt nach dem Aufruf wieder löschen
echo ini_get('session.serialize_handler'), "\n";
echo ini_get('session.upload_progress.enabled'), "\n";

Rufen Sie die Datei einmal im Browser auf und löschen Sie sie sofort danach. Steht in der ersten Zeile php, ist Bedingung 1 nicht erfüllt. Steht dort php_binary oder php_serialize und hatte Schritt 1 einen Treffer, schalten Sie Upload Progress ab.

Schritt 3: Prüfen, ob Sie Upload Progress überhaupt nutzen

grep -rn "PHP_SESSION_UPLOAD_PROGRESS\|upload_progress" /var/www/ --include=*.php

Die Funktion liefert Fortschrittsbalken für Datei-Uploads über die Session. Heute zeigen die meisten Anwendungen den Fortschritt per JavaScript im Browser an und brauchen sie nicht. Ohne Treffer können Sie Upload Progress abschalten, ohne dass Ihnen eine Funktion fehlt. Das GitHub-Advisory zu CVE-2026-109619 rät ohnehin, die Funktion auch nach dem Patch abgeschaltet zu lassen, wenn Sie sie nicht brauchen.

Upload Progress richtig abschalten

Die Einstellung muss gelten, bevor PHP den Upload verarbeitet. Setzen Sie sie deshalb in der php.ini, im FPM-Pool oder in der Server-Konfiguration. Mit ini_set() im Code lässt sich der Wert nicht ändern. Auf eine .user.ini sollen Sie sich laut PHP-Advisory vom 21.10.2026 nicht verlassen.

Starten Sie danach alle PHP-Worker neu, also PHP-FPM, Apache oder den Container. Ohne Neustart läuft die alte Einstellung weiter. Rufen Sie zur Kontrolle die Prüfdatei aus Schritt 2 erneut auf. In der zweiten Zeile muss 0 stehen oder nichts. Löschen Sie die Datei danach wieder.

Läuft Ihre Anwendung noch auf PHP 8.1 oder älter, bekommen Sie den Fix für CVE-2026-115560 nicht vom PHP-Projekt, denn diese Zweige erhalten keine regulären Releases mehr. Sie sind dann auf Backports Ihres Hosters oder Ihrer Distribution angewiesen. Auf Dauer hilft nur die Umstellung auf eine unterstützte PHP-Version. Welche Versionen noch Updates bekommen, zeigt unser Ratgeber zum Support-Ende der PHP-Versionen.

Bei Shared Hosting können Sie die php.ini meist nicht selbst ändern. Manche Hoster bieten PHP-Einstellungen im Kundenmenü an, sonst hilft nur der Support. Was die großen Hoster zu PHP2Shell gemeldet haben, steht in unserer Übersicht zum Stand der Hoster. Fragen Sie konkret, ob session.upload_progress.enabled auf Ihrem Paket abgeschaltet ist.

Was gilt, wenn Sie wegen PHP2Shell schon gehandelt haben?

Haben Sie session.upload_progress.enabled=0 schon am 21.10.2026 gegen CVE-2026-109619 gesetzt, lassen Sie die Einstellung aktiv. Laut PHP ist dann nichts weiter zu tun. Prüfen Sie nur, ob die Einstellung wirklich greift, etwa mit der Prüfdatei aus Schritt 2. Gerade wenn Sie sie damals per .user.ini gesetzt haben, ist das nicht sicher.

Die Einstellung ersetzt die PHP2Shell-Updates nicht. Sie blockiert bei CVE-2026-109619 nur einen Angriffsweg. Lassen Sie die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 oder die Backports Ihrer Distribution installiert. Wie Sie den Patch einspielen und kontrollieren, steht im Ratgeber PHP2Shell technisch erklärt.

Wird CVE-2026-115560 schon ausgenutzt?

Bis zum 23.10.2026 gibt es keine öffentlichen Berichte über Angriffe auf diese Lücke. Einen öffentlichen Proof of Concept kennt laut SecurityOnline bisher niemand. Die Angriffe seit dem 21.10.2026 zielen auf die beiden PHP2Shell-Lücken.

Das kann sich ändern, sobald PHP das vollständige Advisory mit den technischen Details veröffentlicht. Setzen Sie die Einstellung deshalb jetzt, nicht erst dann. Skripte aus dem Netz, die angeblich prüfen, ob Ihr Server verwundbar ist, sollten Sie nicht ausführen. Die Gründe dafür stehen im Abschnitt zu Exploit-Skripten im technischen PHP2Shell-Ratgeber.

Wenn Sie Unterstützung brauchen

Wir betreuen als Digitalagentur PHP-Anwendungen, von WordPress und Shopware bis zu eigenen Laravel-Projekten. Wir prüfen Code und Konfiguration auf die Bedingungen von CVE-2026-115560, setzen die Übergangslösung im passenden Setup und kontrollieren dabei den Stand der PHP2Shell-Updates. Den Ablauf und die Konditionen finden Sie auf der Seite zur PHP2Shell-Bestandsaufnahme.

Stellt eine ältere Eigenentwicklung den Session-Handler selbst um, reicht eine Einstellung auf Dauer nicht. Dann lohnt ein Blick in den Code. Wir modernisieren solche Anwendungen oder lösen sie ab, mehr dazu auf der Seite zur Individualsoftware-Entwicklung.

Quellen

• php.net: Informational advisory: Session upload progress (23.10.2026)
• php.net: Security advisory zu CVE-2026-109618 und CVE-2026-109619 (21.10.2026)
• GitHub: Advisory GHSA-6wmf-4rv5-p3rp des PHP-Projekts
• cve.org: CVE-2026-115560
• PHP Foundation auf X (23.10.2026)
• The Hacker News (23.10.2026)
• SecurityOnline (23.10.2026)
• PHP-Handbuch: Session-Konfiguration
• PHP-Handbuch: Session Upload Progress

Häufige Fragen zu CVE-2026-115560

Reicht das PHP-Update vom 21.10.2026 gegen CVE-2026-115560?

Nein. Die Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 schließen die beiden PHP2Shell-Lücken, aber nicht CVE-2026-115560. Die Korrektur kommt mit dem nächsten regulären Release. Bis dahin hilft die Einstellung session.upload_progress.enabled=0.

Ist meine WordPress-Website betroffen?

Unwahrscheinlich. WordPress selbst nutzt keine PHP-Sessions, und der Standard-Handler ist php. Betroffen wäre die Website nur, wenn ein Plugin den Handler zur Laufzeit von php_binary oder php_serialize auf php umstellt. Eine Suche nach serialize_handler im Plugin-Ordner klärt das.

Geht etwas kaputt, wenn ich Upload Progress abschalte?

Nur Fortschrittsbalken, die den Upload-Stand über die PHP-Session abfragen. Die meisten Anwendungen zeigen den Fortschritt heute per JavaScript im Browser an und merken keinen Unterschied. Datei-Uploads selbst funktionieren weiter.

Kann ich die Einstellung per ini_set() oder .user.ini setzen?

Nein. Mit ini_set() lässt sich der Wert nicht ändern, und eine .user.ini wirkt laut PHP-Advisory vom 21.10.2026 zu spät. Setzen Sie die Einstellung in der php.ini, im FPM-Pool oder in der Server-Konfiguration und starten Sie alle PHP-Worker neu.

Wann veröffentlicht PHP den Fix?

Mit dem nächsten regulären Bugfix-Release. Ein Datum hat PHP für CVE-2026-115560 nicht genannt. Mit dem Release will PHP auch das vollständige Advisory veröffentlichen, mit betroffenen Versionen und technischen Details.

Muss ich etwas tun, wenn ich Upload Progress schon wegen PHP2Shell abgeschaltet habe?

Nein, laut PHP nicht. Lassen Sie die Einstellung aktiv und prüfen Sie einmal, ob sie auf dem Webserver wirklich greift. Die PHP2Shell-Updates bleiben trotzdem nötig, denn die Einstellung blockiert dort nur einen von mehreren Angriffswegen.