Artikel

PHP CVE-2026-115560 im Detail: Session Upload Progress und Serialize-Handler-Mismatch erklärt

Abseits des Clickbaits rund um die PHP-Meldung CVE-2026-115560 (CVSS 6.4): Wie Laufzeitänderungen an session.serialize_handler mit session.upload_progress kollidieren und PHP Object Injection auslösen, und die php.ini-Gegenmaßnahme in einer Zeile.

Furkan Özay24. Oktober 2026 · 3 Min. Lesezeit
czCZAY.DEV // EDITORIALDE
GÜVENLIK

#Güvenlik · 3 MIN LESEZEIT

FURKAN ÖZAYVOL. 2026 // #2AD7

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:

  1. php (Standard): Formatiert Einträge als key|serialized_value (mit dem Pipe-Zeichen | als Trennzeichen).
  2. php_serialize (eingeführt in PHP 5.5.4): Formatiert das gesamte Session-Array mit dem normalen serialize(), 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:

php
// 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:

ini
; Disable legacy server-side upload progress session injection
session.upload_progress.enabled = 0

Starte php-fpm neu (systemctl reload php8.3-fpm), und der gesamte Angriffsvektor ist dauerhaft geschlossen.

Interaktive Roadmap & Tool

Als Nächstes lesen