Zuerst die Versionsnummern: 8.5.11, 8.4.26, 8.3.35, 8.2.34. Diese Releases nannte ein viel geteiltes Medium-Advisory als die, die den Fix für CVE-2026-109618 und CVE-2026-109619 enthalten. Es geht um einen Speichersicherheitsfehler im Code für den Session-Upload-Fortschritt, den das Advisory mit CVSS v4.0 9.2 bewertete und der mit Standardeinstellungen ohne Authentifizierung erreichbar ist. Der Patch war für den 2026-10-21 um 14:00 UTC angekündigt, eine Woche bevor ich das hier schreibe. Bevor du irgendetwas anderes tust, gleich das offizielle Changelog auf php.net und den Security-Tracker deiner Distribution mit dem ab, was bei dir tatsächlich installiert ist. Ein Blogpost ist ein Hinweis, die Quelle der Wahrheit ist das Advisory.

php.ini
session.upload_progress.enabled = Off

Wenn du auf einem dieser Builds bist: gut. Dieses konkrete Loch ist zu. Was mich stört, ist der Schritt, den die meisten von uns als Nächstes gehen werden: die Notfallzeile still und leise wieder aus der php.ini löschen, weil das Incident-Ticket geschlossen ist und sich die Zeile wie ein Baugerüst anfühlt. Ich sehe das genau umgekehrt. Die Notlösung war die nützlichste Änderung, die deine Server in diesem Monat bekommen haben, und das Upgrade hat sie bloß optional gemacht.

Frag dich mal, wann du zuletzt ein Feature ausgeliefert hast, das auf session.upload_progress angewiesen war. Ich habe die vier Codebasen durchgesehen, an denen ich regelmäßig arbeite, darunter eine Laravel-App, die 2016 ihren Anfang nahm, und null Zugriffe auf den Progress-Key in der Session gefunden. Unsere Upload-Fortschrittsbalken kommen alle aus dem Browser, wo die Upload-Events von XHR oder fetch die gesendeten Bytes melden, ohne dass der Server überhaupt irgendeinen Zustand halten muss. Währenddessen war das serverseitige Feature in jedem FPM-Pool standardmäßig aktiv und hat jeden Multipart-Request geparst, für den Fall, dass es doch mal jemand braucht.

Das ist der eigentliche Kern dieses Vorfalls. Code, den niemand aufruft, läuft trotzdem, wenn eine Voreinstellung ihn einschaltet, und Code, der läuft, kann kaputtgehen. Einen Bug in einem Framework oder CMS kann man im Userland patchen; ein Core-Bug wie dieser trifft WordPress, Drupal, deine selbst gebaute API und das vergessene interne Tool gleichermaßen, und solange der Fix fehlt, bleibt dir als einziger Hebel die Konfiguration. Alte Branches machen es noch schlimmer: Laut Advisory bekommen 8.0, 8.1 und alles aus 7.x und 5.x gar nichts. Auf diesen Hosts ist das Abschalten des Features also keine Notlösung, sondern die gesamte Verteidigung.

Jetzt der berechtigte Einwand. Upload-Fortschritt gibt es aus gutem Grund: Er funktionierte schon, bevor Browser Upload-Events zuverlässig bereitstellten, und manche langlebigen Apps, vor allem solche mit serverseitig gerenderten Admin-Panels und einem Polling-Endpoint, hängen noch daran. Wer das Feature global abschaltet, kann unbemerkt einen Fortschrittsbalken lahmlegen, auf den sich irgendein Kunde verlässt, und niemand will eine Sicherheitsänderung, die freitags um 23:40 als Support-Ticket aufschlägt. Außerdem kann man gut argumentieren, dass der richtige Fix in den Core gehört und Ops-Teams nicht jede Voreinstellung hinterfragen müssen sollten, die php-src ausliefert.

Beides stimmt, und an meiner Position ändert keins davon etwas. Ob etwas kaputtgeht, lässt sich hier billig herausfinden: Ein grep nach dem Progress-Session-Key über deine Repositories dauert ungefähr eine Minute, und die Apps, die das Feature brauchen, können es in ihrer eigenen Pool-Konfiguration wieder einschalten, mit einem Kommentar, der erklärt, warum. Damit dreht sich die Beweislast um. Das Feature muss begründen, warum es an ist, statt dass du begründen musst, warum du es abschaltest. Und was die Core-Defaults angeht: Ich fände es gut, wenn php-src sich diesen hier noch einmal vornimmt, aber eine lang etablierte Voreinstellung zu ändern ist aus guten Gründen langsame und sorgfältige Arbeit, und deine Server müssen nicht warten, bis diese Diskussion zu Ende geführt ist.

Dasselbe gilt für die anderen Dinge, die das Advisory empfohlen hat und die du vielleicht in Panik ergänzt hast: open_basedir pro Pool, eine disable_functions-Liste, Alerts, wenn FPM-Worker mit Signal 11 sterben. Nichts davon hält einen entschlossenen Angreifer auf, und genau das steht auch im Write-up. Aber ein Worker-Crash, der innerhalb von Minuten in deinen Logs auftaucht, ist eine Frühwarnung, wie man sie selten bekommt, und ein Pool, der nicht über sein eigenes Verzeichnis hinausschauen kann, macht aus einer schlimmen Nacht eine beherrschbare. Behalt die langweiligen Schutzmaßnahmen, auch wenn die Aufregung vorbei ist.

Deshalb will ich in den Kommentaren wirklich wissen: Betreibt noch jemand serverseitiges session.upload_progress absichtlich in Produktion, und was müsste passieren, damit du den Fortschrittsbalken auf den Client verlagerst? Wenn genug von uns antworten, haben wir vielleicht die Daten, mit denen wir bei php-src eine Änderung der Voreinstellung anstoßen können.