Sobald im PHP-Ökosystem eine neue CVE auftaucht, schreien sensationslüsterne Schlagzeilen sofort von „vollständigen Server-Übernahmen ohne Authentifizierung“. Als die PHP Group CVE-2026-115560 (CVSS 6.4) veröffentlichte (GHSA-4966-6377-397r), wurde sie in Gerüchten schnell mit Schwachstellen in HTTP-Wrappern verwechselt.
Als Backend-Entwickler ist es nicht unsere Aufgabe, bei Schlagzeilen in Panik zu geraten – wir lesen die ursprüngliche Sicherheitsmeldung und verstehen den genauen Ausführungspfad. Schauen wir uns an, was CVE-2026-115560 tatsächlich ist, warum sie auftritt, welche Anwendungen wirklich betroffen sind und wie du sie mit einer einzigen Zeile in der php.ini entschärfst.
1. Der Kernmechanismus: Wie PHP Sessions serialisiert
PHP unterstützt mehrere interne Formate (session.serialize_handler), um die Superglobale $_SESSION zu kodieren, bevor sie auf die Festplatte oder nach Redis geschrieben wird:
php(Standard): Formatiert Einträge alskey|serialized_value(mit dem Pipe-Zeichen|als Trennzeichen).php_serialize(eingeführt in PHP 5.5.4): Formatiert das gesamte Session-Array mit dem normalenserialize(), ohne spezielle Pipe-Trennzeichen.
Solange eine Anwendung beim Schreiben und Lesen einer Session exakt denselben Serializer verwendet, ist alles sicher. Gefährlich wird es, wenn Daten mit php_serialize geschrieben werden (das rohe |-Zeichen in Strings erlaubt) und später mit dem php-Handler wieder gelesen werden (der alles nach dem | als serialisiertes PHP-Objekt behandelt!).
2. Wo session.upload_progress ins Spiel kommt
Wenn in der php.ini session.upload_progress.enabled = 1 aktiv ist, untersucht PHP Multipart-Datei-Uploads, BEVOR dein Anwendungscode (index.php) überhaupt anfängt zu laufen. Enthält der Upload ein Feld PHP_SESSION_UPLOAD_PROGRESS, initialisiert die PHP-Engine die Session während der Startphase der Anfrage automatisch mit dem in der php.ini definierten Standard-Serializer.
Die Schwachstelle in CVE-2026-115560
Was passiert, wenn dein PHP-Code den Handler anschließend zur Laufzeit ändert mit:
// Changing the serializer dynamically at runtime before session_start()
ini_set('session.serialize_handler', 'php_serialize');
session_start();Weil der Upload-Progress-Tracker die Session-Strukturen bereits unter einer anderen Handler-Erwartung initialisiert hat, kommt es zu einem Serializer-Mismatch zwischen dem Upload-Progress-Payload und dem Session-Decoder zur Laufzeit.
Ein Angreifer kann einen Multipart-Upload senden, dessen Payload mit einem Pipe-Zeichen beginnt (|O:8:"Exploit":...). Wenn der nicht passende Handler die Session-Datei deserialisiert, löst das PHP Object Injection (Deserialization of Untrusted Data) aus!
Info: Warum nur CVSS 6.4 statt 9.8?
Anders als universelle RCE-Schwachstellen setzt CVE-2026-115560 zwei konkrete Voraussetzungen voraus: session.upload_progress.enabled muss aktiviert sein UND die Anwendung muss session.serialize_handler zur Laufzeit per ini_set() dynamisch überschreiben. Standard-Anwendungen mit Laravel oder Symfony, die Sessions statisch konfigurieren, sind vom Laufzeit-Mismatch nicht betroffen.
3. Sofortmaßnahmen und gepatchte PHP-Versionen
Schritt 1: PHP aktualisieren
Das PHP-Team hat diesen Lifecycle-Mismatch in den offiziellen Sicherheitsreleases vom Oktober 2026 behoben:
- PHP 8.3.x ➔ Auf die gepatchte Version aktualisieren
- PHP 8.4.x / 8.5.x ➔ Auf die gepatchte Version aktualisieren
Schritt 2: session.upload_progress in der php.ini deaktivieren
Moderne Webanwendungen verfolgen den Fortschritt von Datei-Uploads clientseitig mit JavaScript (XMLHttpRequest.upload.onprogress oder Fetch-Streams). Damit ist das veraltete serverseitige Upload-Progress-Tracking von PHP über Sessions völlig überflüssig – und eine wiederkehrende Angriffsfläche.
Öffne die php.ini deines Produktivsystems und deaktiviere es dauerhaft:
; Disable legacy server-side upload progress session injection
session.upload_progress.enabled = 0Starte php-fpm neu (systemctl reload php8.3-fpm), und der gesamte Angriffsvektor ist dauerhaft geschlossen.
Interaktive Roadmap & Tool
Junior Backend Developer 2026
Was du wirklich wissen musst, um 2026 eine Junior-Backend-Stelle zu bekommen, und was warten kann – ohne die Buzzword-Fallen aus echten Stellenanzeigen.
SQL oder NoSQL?
Beantworte sechs Fragen, und ich sage dir, welche Art von Datenbank zu deinem Projekt passt und warum.
Als Nächstes lesen
- CZDEDurch den Dschungel: Welche Backend-Sprache und welches Framework solltest du 2026 wählen?
Durch den Dschungel: Welche Backend-Sprache und welches Framework solltest du 2026 wählen?
25. Oktober 2026 · 3 Min. Lesezeit - CZDEWas ist eine IDOR-Schwachstelle? Authentication vs. Authorization und wie du BOLA verhinderst
Was ist eine IDOR-Schwachstelle? Authentication vs. Authorization und wie du BOLA verhinderst
24. Oktober 2026 · 3 Min. Lesezeit