Zwei kritische RCEs im PHP-Kern: was betroffen ist und wie du patchst

Am 21. Oktober 2026 hat das PHP-Projekt 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, und das Advisory sagt es ohne Umschweife: jetzt aktualisieren. Die Releases schließen zwei kritische Lücken, die Remote Code Execution ohne Authentifizierung erlauben können, und das Advisory zählt jede PHP-Installation, die Web-Requests bedient, als gefährdet: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Wenn du Laravel, WordPress oder sonst etwas auf PHP betreibst, geht es hier um die Runtime unter deinem Code, nicht um deinen Code. In deiner Anwendung muss nichts falsch sein, damit dich das betrifft.

Die beiden Bugs

CVE-2026-109618 betrifft den Umgang mit Speichermangel. Ein fehlgeschlagener Allocation-Versuch kann PHP unterbrechen, während interne Request-Daten erst halb aufgebaut sind, und das Aufräumen am Ende des Requests behandelt diese halbfertigen Daten dann womöglich als gültig. Das GitHub-Advisory ergänzt, dass mehrere Pfade beim Parsen von Multipart-Uploads diesen Out-of-Memory-Zustand erreichen können, obwohl der Request noch innerhalb seiner Limits zu liegen scheint. CVE-2026-109619 betrifft veralteten Zustand: Etwas, das zu einem Request gehört, kann den Speicher dahinter überleben, und der nächste Request auf demselben Worker benutzt es möglicherweise, bevor die normale Initialisierung es zurücksetzt.

Der externe Tracker pwn.watch nennt das Paar „PHP2Shell“, bewertet beide mit CVSS 9.2 und schreibt, die Details seien nach einem Leck vor Ablauf des Embargos früh öffentlich geworden. Laut demselben Tracker gab es Exploit-Versuche vor und nach dem Patch, watchTowr und AWS melden aktive Scans, und Appliance-Hersteller wie QNAP arbeiteten noch an ihren Fixes. Das sind die Angaben des Trackers; was du installieren musst, sagt dir das Advisory auf php.net.

Welche Setups am stärksten betroffen sind

Das Risiko ist nicht für jede Server-API gleich. Das GitHub-Advisory erklärt den Grund: mod_php führt den Request-Shutdown immer aus, auch wenn der Request-Start fehlgeschlagen ist. Läuft beim Parsen des Bodys der Speicher aus, wird also ein ungültiger Zustand verarbeitet, bevor überhaupt Anwendungscode läuft, und genau dort wurde ein funktionierender Exploit gezeigt. PHP-FPM beendet den Child-Prozess, wenn der Start fehlschlägt, und nimmt ihn damit aus dem Pool; laut Quellcode-Analyse ist FPM trotzdem anfällig, ein vollständiger FPM-Exploit wurde aber nicht gezeigt. FrankenPHP ist wahrscheinlich auf dieselbe Weise anfällig wie mod_php, und LSAPI von LiteSpeed verhält sich wie FPM.

Jedes PHP finden, dann der Reihe nach patchen

Grundsätzlich kann auf einem Server mehr als ein PHP liegen, und php -v im Terminal meldet das Kommandozeilen-Binary, das nicht immer dasselbe ist, das der Webserver nutzt. Prüf jede Stelle, an der sich eine Version verstecken kann: die CLI, den FPM-Dienst, jedes Docker-Image, das du baust oder ziehst, und die PHP-Auswahl im Hosting-Panel.

# the command-line PHP (may differ from the web one)
php -v
# the PHP inside a container image you deploy
docker run --rm your-image:tag php -v

Welche Version der Webserver wirklich ausführt, verrät eine temporäre Datei mit einem einzigen Request. Lösch sie gleich danach wieder.

<?php
echo PHP_VERSION, ' ', PHP_SAPI;

Alles unter 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist betroffen. Linux-Distributionen und Anbieter von Langzeit-Support haben die Patches vorab bekommen, also schau zuerst in die Pakete deines Anbieters. Das Advisory weist darauf hin, dass das ehrenamtlich betriebene rpms.remirepo.net am Release-Tag keine Updates haben würde, und empfiehlt stattdessen Distributionspakete oder einen Build aus den Quellen. PHP 8.1 und älter bekommen vom PHP-Projekt keine Updates mehr; manche Anbieter portieren zurück, und das Security-Team hat minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht, für alle, die selbst bauen.

Starte nach dem Update jeden PHP-Worker neu. Ein lang laufender FPM-Pool oder ein FrankenPHP-Worker behält das alte Binary im Speicher, bis er neu gestartet wird.

Was die Workarounds leisten und was nicht

Das Advisory ist da eindeutig: Das Update ist die einzige vollständige Lösung, und die aufgeführten Maßnahmen verringern das Risiko auf bestimmten Pfaden, ohne eine Installation sicher zu machen. Für den Speicher-Bug gehören dazu: memory_limit=-1 dort, wo Anwendungen es nicht überschreiben können (php_admin_value im FPM-Pool oder in der Apache-Konfiguration), ein niedriges post_max_size (8M ohne Uploads, 32M mit, und upload_max_filesize darunter), Limits am Webserver oder Proxy für Request-Größe, Feldanzahl, Multipart-Teile, Header und Verschachtelung, und ein Speicherlimit über Container oder cgroup statt RLIMIT_AS oder RLIMIT_DATA, die genau den fraglichen Allocation-Fehler auslösen können. Für den Bug mit veraltetem Zustand: session.upload_progress.enabled=0 in php.ini oder der Pool-Konfiguration (nicht per ini_set() oder .user.ini) mit Neustart aller Worker, fatal_error_backtraces=0 unter 8.5, das Entfernen ungültiger oder veralteter Einstellungen pro Request, und das Beheben von Fatal Errors und Timeouts, die ein Angreifer auslösen kann.

Der konkrete Schritt für heute: Liste jeden Server, jedes Container-Image und jeden Hosting-Account auf, auf dem PHP läuft, notiere die Version, die jeweils ausgeliefert wird, und aktualisiere alles unter den gefixten Releases, bevor du irgendeine Einstellung anfasst. Quelle: php.net, Security-Advisory vom 21. Oktober 2026.