Kurz gesagt: CVE-2026-109618 ist eine der beiden Lücken hinter PHP2Shell. Ein Out-of-Memory-Zustand kann PHP unterbrechen, während Anfragedaten erst teilweise initialisiert sind; beim Aufräumen können ungültige Daten dann als gültig gelten. Das ermöglicht Codeausführung ohne Anmeldung. Behoben ist der Fehler in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.
Was ist CVE-2026-109618?
CVE-2026-109618 (GitHub-Kennung GHSA-w8hw-w9fx-j79w) ist eine Speicherfehler-Lücke im Kern von PHP. Sie ist mit CVSS v4.0 9.2 bewertet. Zusammen mit CVE-2026-109619 bildet sie das, was in den Medien als PHP2Shell bezeichnet wird.
Die Wirkung ist eine sogenannte unauthenticated Remote Code Execution: Ein Angreifer kann aus der Ferne und ohne Benutzerkonto Code auf dem Webserver ausführen. Damit gehört die Lücke zur gefährlichsten Klasse von Schwachstellen, die ein Webserver haben kann.
Wie die Lücke grundsätzlich entsteht
Wenn PHP eine Webanfrage verarbeitet, legt es intern Datenstrukturen für diese Anfrage an, etwa für übermittelte Formulardaten. Läuft PHP dabei an seine Speichergrenze, bricht es mit einem Out-of-Memory-Zustand ab. Laut php.net kann das passieren, während die Anfragedaten erst teilweise initialisiert sind.
Am Ende jeder Anfrage räumt PHP auf und gibt den Speicher frei. Genau dort liegt der Fehler: Das Aufräumen kann ungültige, nur halb angelegte Daten als gültig behandeln. Aus diesem Fehlverhalten lässt sich unter bestimmten Bedingungen Codeausführung ableiten.
Warum ist ein solcher Fehler so ernst? Ein Speicherfehler in der Programmiersprache betrifft alle Anwendungen, die darauf laufen, unabhängig davon, wie sorgfältig sie programmiert sind. Eine gepflegte WordPress-Installation mit aktuellen Plugins ist genauso betroffen wie eine alte Eigenentwicklung. Deshalb hilft hier kein Update der Anwendung, sondern nur ein Update von PHP.
Weitere technische Einzelheiten zur Ausnutzung veröffentlichen wir bewusst nicht. Für die Verteidigung sind sie nicht nötig: Entscheidend ist, ob Ihr Server eine behobene Version nutzt und ob die neuen Prozesse tatsächlich laufen.
Betroffene Versionen und Betriebsarten
| PHP-Zweig | Letzter Stand vor dem Fix | Behoben ab |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 und älter | kein offizielles Update | nur minimale Quell-Backports für 7.4, 8.0, 8.1 |
Betroffen sind die Betriebsarten PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team stuft das Risiko bei mod_php am höchsten ein. Distributionen und Hoster spielen teils Backports ein, sodass eine ältere Versionsnummer angezeigt wird, obwohl der Fehler behoben ist. Maßgeblich sind Paketstand und Bestätigung des Anbieters.
Zur Größenordnung: Palo Alto Networks (Unit 42) zählte mehr als 22,6 Millionen exponierte, potenziell verwundbare Instanzen. Das BSI hat Warnstufe 3 (Orange) ausgerufen und rechnete mit schneller großflächiger Ausnutzung.
CVE-2026-109618 beheben: Update und Neustart
Die einzige vollständige Abhilfe ist das Update. Prüfen Sie zuerst Version und Paketstand. Paketnamen weichen je Distribution ab; die Beispiele gehen von PHP 8.3 aus:
php -v
apt policy php8.3-fpm # Debian/Ubuntu
dnf info php-fpm # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"
Nennt der Paket-Changelog die CVE-Nummer, ist der Backport eingespielt. Fehlt sie, heißt das nicht automatisch, dass das Paket verwundbar ist; dann hilft der Abgleich mit der Versionstabelle oder die Rückfrage beim Anbieter.
Nach dem Update müssen alle PHP-Prozesse neu gestartet werden, zum Beispiel mit systemctl restart php8.3-fpm oder bei mod_php mit einem Neustart von Apache. Wie Sie sicherstellen, dass kein alter Worker mehr läuft, steht unter PHP-FPM und alle Worker neu starten.
Übergangsmaßnahmen, wenn das Update noch nicht geht
php.net hat für PHP2Shell Übergangsmaßnahmen veröffentlicht. Sie gelten für beide Lücken gemeinsam und sind ausdrücklich kein vollständiger Schutz. Dass sich mehrere davon auf Speichergrenzen beziehen, passt zum Out-of-Memory-Auslöser von CVE-2026-109618; eine offizielle Zuordnung einzelner Maßnahmen zu einzelnen CVEs gibt es aber nicht.
; Beispiel FPM-Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf (Pfad je Distribution verschieden)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M ; 32M, wenn Uploads nötig sind
php_admin_value[upload_max_filesize] = 6M ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off
Die Werte müssen so gesetzt sein, dass Anwendungen sie nicht überschreiben können, daher php_admin_value. Mit memory_limit=-1 braucht der Dienst eine Speichergrenze von außen, über Container oder cgroup, nicht über RLIMIT_AS oder RLIMIT_DATA. Auf PHP 8.5 kommt fatal_error_backtraces=0 hinzu. Alle Details stehen unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
Wenn weder Update noch Übergangsmaßnahmen sofort möglich sind, empfiehlt das BSI, betroffene Webserver vorübergehend vom Netz zu nehmen.
Wie hilft PHP SOS konkret?
Über unseren PHP-Patch-Service schließen wir CVE-2026-109618 strukturiert:
- Ist-Stand erfassen: PHP-Zweig, Betriebsart, Paketquelle und Backport-Stand je Server.
- Update einspielen aus der passenden Paketquelle oder, wo das nicht geht, die Übergangsmaßnahmen sauber in Pool- oder Serverkonfiguration setzen.
- Neustart prüfen: Wir kontrollieren, dass keine alten PHP-Prozesse mehr laufen.
- Nachweis: Sie erhalten eine Dokumentation mit Versionen und Paketständen vor und nach dem Eingriff, etwa für Geschäftsführung, Versicherer oder Datenschutz.
Häufige Fragen
Wie kritisch ist CVE-2026-109618?
Die Lücke ist mit CVSS v4.0 9.2 bewertet und damit kritisch. Sie ermöglicht Ausführung von Schadcode aus der Ferne ohne Anmeldung. Das BSI hat zu PHP2Shell die Warnstufe 3 (Orange) ausgerufen.
Reicht es, memory_limit hochzusetzen?
Nein. php.net nennt memory_limit=-1, fest in der Serverkonfiguration gesetzt, als eine von mehreren Übergangsmaßnahmen. Sie ist ausdrücklich kein vollständiger Schutz und braucht eine Speichergrenze über Container oder cgroup. Die Lösung bleibt das Update.
Welche GHSA-Kennung gehört zu CVE-2026-109618?
Im GitHub Security Advisory ist die Lücke unter GHSA-w8hw-w9fx-j79w geführt. Die zweite PHP2Shell-Lücke, CVE-2026-109619, hat die Kennung GHSA-6wmf-4rv5-p3rp.