Kurzantwort: Betroffen sind PHP-Versionen vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12, sofern deine Distribution keinen entsprechenden Sicherheits-Backport eingespielt hat. Ein Update auf einen gepatchten Stand ist die einzige vollständige Behebung. Die Ausnutzbarkeit hängt zusätzlich von der eingesetzten SAPI ab.
Warum ist CVE-2026-109618 relevant?
Am 21. Oktober 2026 hat das PHP-Team zwei kritische Sicherheitsupdates veröffentlicht, die als "php2shell" bekannt wurden. CVE-2026-109618 heißt im offiziellen Advisory "RCE via OOM corruption" und wird mit CVSS 4.0 mit 9,2 bewertet. Das BSI stuft die Lage mit Kritikalität 3 (Orange) ein und empfiehlt, den Patch unverzüglich zu installieren.
Laut BSI lagen keine bestätigten Angriffe vor, aber unbestätigte Exploit-Berichte. Wer PHP im Internet betreibt, sollte nicht warten.
Was ist CVE-2026-109618?
PHP behandelt Speicherknappheit intern mit longjmp(). Schlägt eine Allokation fehl, kann die Runtime den Request vorzeitig verlassen, obwohl die Request-Daten nur teilweise initialisiert sind. Die Aufräumphase behandelt diesen Zustand als gültig und liest unvollständigen Speicher. Daraus entsteht eine Speicherkorruption bis hin zu Remote Code Execution. Die fehlgeschlagene Allokation muss dabei nicht mit dem beschädigten Bereich zusammenhängen.
Welche Rolle spielen HTTP-Requests und Multipart-Parsing?
PHP verarbeitet den Request-Body, bevor der eigentliche Anwendungscode läuft. Bei multipart/form-data erzeugt der Parser Metadaten für jedes Teil, für Header und für Dateifelder. Das Advisory nennt unter anderem:
- Multipart-Requests ohne verwertbare Content-Length
- Teile mit vielen Headern, deren interne Darstellung mehr Speicher belegt als das Wire-Format
- Leere Datei-Felder, die
max_file_uploadsumgehen, aber Metadaten anlegen - Tief verschachtelte Feldnamen, die den Aufwand vervielfachen
- Anwendungsspezifische Allokationen, die ein Angreifer wiederholt auslösen kann
Deshalb ist eine Anwendung auch dann gefährdet, wenn sie selbst keine Upload-Funktion besitzt. Der Parser der Runtime sieht den Request trotzdem.
Welche Voraussetzungen muss ein Angriff erfüllen?
Der Dienst muss über das Netz erreichbar sein. Authentifizierung und Nutzerinteraktion sind nicht erforderlich, die Angriffskomplexität gilt mit AC:H aber als hoch. Der Angreifer muss eine OOM-Situation beeinflussen können. Die Zuverlässigkeit hängt von Build, Extensions, Webserver und Allocator-Layout ab. Die Version entscheidet über die Betroffenheit, die SAPI über den realen Angriffsweg.
Welche PHP-Versionen sind betroffen?
Die offiziellen Angaben aus dem PHP-Advisory:
| PHP-Zweig | Betroffen | Erster sicherer Release |
|---|---|---|
| PHP 8.5 | vor 8.5.12 | 8.5.12 |
| PHP 8.4 | vor 8.4.27 | 8.4.27 |
| PHP 8.3 | vor 8.3.36 | 8.3.36 |
| PHP 8.2 | vor 8.2.35 | 8.2.35 |
Für ältere Zweige gibt es keine Upstream-Patches. CERT-EU und BSI halten mindestens alle Versionen ab PHP 5 für verwundbar. PHP 8.1 und älter sind End-of-Life.
Distributionen portieren Fixes zurück. Ubuntu hat für CVE-2026-109618 bereits Pakete veröffentlicht: php8.1 in Jammy mit 8.1.2-1ubuntu2.28, php8.3 in Noble mit 8.3.6-0ubuntu0.24.04.13 und php8.5 in 26.04 LTS sowie 26.10. Prüfe das Advisory deiner Distribution.
Warum reicht php -v nicht aus?
php -v zeigt die Upstream-Version, nicht die Paketrevision. Ein System kann "PHP 8.3.6" melden und dennoch einen schützenden Backport enthalten, während ein aktueller Container ein altes Image nutzt.
CLI und FPM sind oft getrennte Pakete. Ein gepatchtes CLI bedeutet nicht automatisch einen gepatchten FPM-Worker. Prüfe Version, SAPI und Paketstand getrennt.
Welche Webserver und SAPIs sind gefährdet?
Das Advisory unterscheidet ausdrücklich zwischen nachgewiesener und theoretischer Ausnutzbarkeit:
| SAPI / Webserver | Einordnung laut Advisory |
|---|---|
| Apache mit mod_php | Über HTTP nachgewiesen ausnutzbar. Request-Shutdown wird auch nach fehlgeschlagenem Startup ausgeführt. |
| PHP-FPM | Quellcodeanalyse spricht für Anfälligkeit, ein vollständiger FPM-Exploit wurde nicht demonstriert. |
| FrankenPHP | Wahrscheinlich anfällig, weil das Shutdown-Verhalten dem von mod_php ähnelt. Nicht validiert. |
| LiteSpeed / LSAPI | Ähnlich wie FPM. Anwendungsspezifische Ausnutzung plausibel, aber nicht validiert. |
mod_php ist der bestätigte Angriffsweg. FPM, FrankenPHP und LSAPI sind nicht entwarnt, aber auch nicht mit einem vollständigen Exploit belegt. Wer sie einsetzt, sollte den Patch priorisieren.
Wie prüfst du deine PHP-Applikation?
Schritt 1: PHP-Version auf dem Host feststellen
php -vSchritt 2: Version im Container prüfen
docker exec <container-name> php -vPrüfe jeden Webserver- und Worker-Container, nicht nur die CLI.
Schritt 3: Tatsächlich verwendete Runtime prüfen
Ein minimaler Diagnose-Endpunkt zeigt SAPI und zentrale Limits:
<?php
header('Content-Type: text/plain');
echo "PHP Version: " . PHP_VERSION . "\n";
echo "SAPI: " . PHP_SAPI . "\n";
echo "memory_limit: " . ini_get('memory_limit') . "\n";
echo "post_max_size: " . ini_get('post_max_size') . "\n";
echo "max_input_nesting_level: "
. ini_get('max_input_nesting_level') . "\n";
Diesen Endpunkt intern oder authentifiziert betreiben und nach der Prüfung entfernen; er liefert Angreifern sonst eine Bestandsaufnahme.
Schritt 4: Distributionspaket und Patchstand prüfen
dpkg-query -W 'php8.3-fpm'Gleiche die Paketrevision mit dem Security-Advisory der Distribution ab. Ubuntu führt den Status auf der CVE-Seite, Debian und Red Hat in ihren jeweiligen Trackern.
Schritt 5: Ergebnis bewerten
| Befund | Bewertung |
|---|---|
| Version entspricht dem sicheren Release | gepatcht |
| Ältere Version, aber Distributions-Backport enthält den Fix | gepatcht, Backport verifizieren |
| Ältere Version ohne Backport | betroffen, sofort patchen |
| End-of-Life-Zweig ohne Hersteller-Support | betroffen, Migration planen |
| Gepatchtes Paket, aber alter Prozess oder altes Image läuft | unsicher, neu starten oder Image neu bauen |
Die Prüfung belegt den Patchstand, nicht die Ausnutzbarkeit. Ein sauberes Ergebnis ist eine Momentaufnahme.
Welche Angriffsmöglichkeiten sind dokumentiert?
Offiziell beschrieben sind OOM-Vektoren über Multipart-Requests, Header-reiche Teile, leere Datei-Felder und verschachtelte Feldnamen, dazu anwendungsspezifische Allokationen.
Bestätigt ist die Ausnutzung über mod_php im Test des Advisorys. Für FPM und die übrigen SAPIs nennt es Bedingungen und Quellcodebefunde, aber keinen vollständigen Exploit. Öffentliche PoCs gelten als unbestätigt.
Das Fehlen einer Upload-Funktion ist keine Entwarnung. Auch ein Framework wie Symfony, Laravel oder WordPress schützt nicht, weil die Schwachstelle unterhalb der Anwendungsebene liegt.
Welche Maßnahmen schützen?
Priorität hat der Patch. Installiere 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, beziehungsweise die gepatchte Paketversion deiner Distribution. Bei Containern reicht ein Paketupdate im laufenden Container nicht: Image neu bauen und alle Instanzen ersetzen. Backports zählen nach dem Distributions-Advisory.
Requests am Reverse Proxy begrenzen. Setze in nginx zum Beispiel client_max_body_size 8m;, in Apache LimitRequestBody 8388608. Ergänze Rate-Limits. Das reduziert die Angriffsfläche, ersetzt aber keinen Patch.
Multipart nur dort erlauben, wo es benötigt wird. Ohne Datei-Uploads kannst du multipart/form-data am Frontend blockieren. Begrenze zusätzlich die Zahl der Teile und Header pro Teil.
PHP-Limits prüfen. post_max_size, max_input_nesting_level, max_input_vars und max_file_uploads sollten zum Anwendungsfall passen. Ein niedriger post_max_size hilft jedoch nicht zuverlässig bei Requests ohne verwertbare Content-Length. Deshalb sind Limits am Proxy zusätzlich wichtig.
Worker neu starten. Nach Update oder Konfigurationsänderung müssen alle PHP-Prozesse neu starten: FPM-Worker, Apache-Kinder, Container. Ein Reload ohne Prozessaustausch kann alte Module weiterlaufen lassen.
Was ist mit memory_limit=-1?
Das Advisory nennt memory_limit=-1 als Übergangslösung. Das ist keine vollständige Behebung: Eine Allokation kann weiterhin fehlschlagen und den verwundbaren Pfad auslösen. Danach müssen alle Worker neu starten, und keine andere Konfiguration darf ein endliches Limit setzen.
Ohne Limit kann ein einzelner Request den gesamten Arbeitsspeicher des Hosts verbrauchen; der OOM-Killer beendet dann womöglich Master und Worker. Das BSI hält keinen Workaround für zuverlässig. memory_limit=-1 ist deshalb allenfalls eine befristete Notlösung.
Ein cgroup-Limit ist nur ein Teilersatz: Das Beenden der Gruppe kann Master und Worker mitnehmen. RLIMIT_AS und RLIMIT_DATA sollten vermieden werden, da eine erzwungene Allokationsfehlermeldung den verwundbaren longjmp()-Pfad auslösen kann.
Wie hängt CVE-2026-109619 damit zusammen?
CVE-2026-109619 wird als "RCE via stale global state" geführt und mit demselben Score bewertet. Die Ursache ist eine andere: Worker-globale Zustände können Zeiger auf request-eigenen Speicher halten. Wird ein Reset übersprungen, greift ein späterer Request auf freigegebenen Speicher zu. Es ist ein Use-after-Free, keine OOM-Korruption.
Beide Lücken werden durch dieselben Releases geschlossen. Für 109619 nennt das Advisory zusätzliche Übergangsmaßnahmen: fatal_error_backtraces=0 in PHP 8.5 und session.upload_progress.enabled=0, jeweils mit Neustart aller Worker. Diese Flags ersetzen keinen Patch. Die CVEs sollten technisch nicht gleichgesetzt werden.
Fazit
CVE-2026-109618 ist eine Runtime-Schwachstelle, die aus einem Fehlerpfad eine Remote-Code-Execution machen kann. Die Version entscheidet über die Betroffenheit, die SAPI über den Angriffsweg. mod_php ist bestätigt, die übrigen SAPIs sind nicht entwarnt.
Die Reihenfolge: Patch einspielen, Worker und Container neu starten, Patchstand verifizieren, Angriffsfläche reduzieren. memory_limit=-1 ist kein Ersatz. Bei Bestandsaufnahme, Patch-Rollout oder Härtung steht dir das Profi-Team von Bytes Commerce zur Seite.
Checkliste
- ☐ Alle PHP-Installationen, Versionen, SAPIs und Paketrevisionen erfassen
- ☐ Distributions-Advisory und Backport-Status abgleichen
- ☐ Gepatchtes Release installieren
- ☐ Images neu bauen und alle Worker neu starten
- ☐ Patchstand nach dem Neustart erneut verifizieren
- ☐ Diagnose-Endpunkt wieder entfernen
- ☐ Request-Größen und Multipart am Proxy begrenzen
- ☐ PHP-Limits anpassen und Logs auf Auffälligkeiten überwachen
Quellen
- PHP Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
- PHP Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
- BSI: PHP - Kritische Schwachstellen bedrohen Webanwendungen weltweit
- Ubuntu Security: CVE-2026-109618
- CERT-EU Security Advisory 2026-018
- PHP Releases
- Borncity: php2shell - PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619
Fragen & Antworten