--- title: "PHP2Shell (CVE-2026-109618/109619): PHP jetzt patchen" description: "Zwei RCE-Lücken in PHP ohne Login. Behoben in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Welche Pakete den Fix haben und was jetzt zu tun ist." source: "https://wardio.net/de/guides/php2shell-cve-2026-109618/" --- **Patching** # PHP2Shell: CVE-2026-109618 und CVE-2026-109619 Zwei Lücken in PHP selbst, nicht in einem Framework oder Plugin, über die ein Angreifer ohne Anmeldung Code auf dem Server ausführen kann. Läuft auf einem Server PHP für eine Website, ist das heute das wichtigste Update. Von David Kabel · Aktualisiert 2026-10-22 · 5 Min. Lesezeit **Kurz gesagt** Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das korrigierte Paket Ihrer Distribution, und starten Sie alle PHP-FPM-Pools neu. Beide Lücken haben CVSS v4.0 9.2 und erlauben einem nicht angemeldeten Angreifer, Code auf dem Server auszuführen. Das PHP-Sicherheitsteam schreibt, dass es keine vollständige Abhilfe gibt. PHP 8.1 und älter bekommen kein offizielles Release. ## Was die beiden Lücken sind **CVE-2026-109618, RCE über Speichermangel.** Geht PHP im falschen Moment der Speicher aus, können Request-Daten halb initialisiert zurückbleiben, und das Aufräumen behandelt sie danach als gültig. Wer einen Request in diesen Zustand bringen kann, kann den Speicher beschädigen. **CVE-2026-109619, RCE über veralteten globalen Zustand.** Ein Teil des Zustands, der zu einem Request gehört, bleibt in einer globalen Variable stehen, nachdem der Speicher des Requests freigegeben wurde. Der nächste Request auf demselben Worker kann ihn verwenden, bevor die normale Initialisierung ihn zurücksetzt. Das ist ein Use-after-free. Das Advisory bestätigt zwei Wege: frühe INI-Diagnosemeldungen und Session Upload Progress, das standardmäßig aktiv ist und keinen Aufruf von `session_start()` durch die Anwendung braucht. Ubuntu liefert Fixes für seine Pakete bis zurück zu PHP 5, gehen Sie also davon aus, dass jede Version, die Sie betreiben, betroffen ist. watchTowr, das am selben Tag eine FAQ veröffentlicht hat, meldet Ausnutzung in freier Wildbahn. Die Ankündigung des PHP-Projekts selbst sagt das nicht, betrachten Sie es also als gemeldet, nicht als bestätigt. ## Wo der Fix zu finden ist | Quelle | Korrigierte Version | Hinweise | | --- | --- | --- | | PHP upstream | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | Quellcode und Windows-Builds auf php.net | | Debian 13 trixie | php8.4 8.4.27-1~deb13u1 | DSA-6574-1, trixie-security | | Debian 12 bookworm | php8.2 8.2.35-1~deb12u1 | DLA-4848-1, über Debian LTS | | Ubuntu 26.04 LTS | php8.5 8.5.4-0ubuntu1.5 | Ubuntu-Security-Pocket | | Ubuntu 24.04 LTS | php8.3 8.3.6-0ubuntu0.24.04.13 | Ubuntu-Security-Pocket | | Ubuntu 22.04 LTS | php8.1 8.1.2-1ubuntu2.28 | Ubuntu-Security-Pocket | | Offizielle Docker-Images | php:8.5, php:8.4 und die Punkt-Tags | Am 21. Oktober 2026 neu gebaut; eigene Images müssen Sie trotzdem neu bauen | Wenn Sie das ehrenamtlich gepflegte Remi-Repository nutzen: Laut PHP-Team hatte es am Release-Tag keine Updates. Das Team empfiehlt Distributionspakete oder einen Build aus dem Quellcode. ## Prüfen, was Sie betreiben ``` # Welches PHP läuft tatsächlich im Webserver? CLI und FPM können abweichen. php -v php-fpm8.4 -v # Debian/Ubuntu, Version anpassen dpkg -l 'php*-common' | awk '/^ii/ {print $2, $3}' rpm -q php-common # RHEL-Familie # Ist die riskante Voreinstellung noch aktiv? (Abhilfe für CVE-2026-109619) php -i | grep session.upload_progress.enabled ``` Prüfen Sie das FPM-Binary oder die Paketversion, nicht nur `php -v`. Auf Servern mit mehreren parallel installierten PHP-Versionen ist die CLI oft nicht die Version, die die Seite ausliefert. ## Aktualisieren und neu starten ``` # Debian / Ubuntu sudo apt update && sudo apt install --only-upgrade 'php8.*' sudo systemctl restart php8.4-fpm # jede FPM-Version, die Sie betreiben sudo systemctl reload apache2 # falls Sie mod_php nutzen # RHEL-Familie sudo dnf upgrade 'php*' sudo systemctl restart php-fpm httpd ``` Das Paket-Upgrade allein reicht nicht. Alte FPM-Worker halten den verwundbaren Code im Speicher, bis sie neu starten. In Containern ziehen Sie das neue Basis-Image und bauen neu. Ein laufender Container ändert sich nicht, nur weil das Tag auf Docker Hub weitergewandert ist. ## Wenn Sie heute nicht aktualisieren können Das PHP-Sicherheitsteam hat Notlösungen veröffentlicht, die die bestätigten Angriffswege schließen. Es betont, dass sie das Risiko verringern und einen Server nicht sicher machen: ``` ; Nur Notlösungen des PHP-Sicherheitsteams. Kein Fix. ; In php.ini oder im FPM-Pool (php_admin_value) setzen, nicht per ini_set() oder .user.ini session.upload_progress.enabled = 0 post_max_size = 8M ; 32M, wenn die Seite Uploads annimmt ; Nur PHP 8.5: fatal_error_backtraces = 0 ``` Starten Sie danach alle Worker neu. Das Team empfiehlt außerdem, Request-Größe, Feldanzahl und Multipart-Teile im Webserver oder Proxy zu begrenzen und statt `RLIMIT_AS` oder `RLIMIT_DATA` ein Speicherlimit per Container oder cgroup zu nutzen, da diese genau den Allokierungsfehler auslösen können, der die Lücke erreicht. `memory_limit=-1` entfernt das PHP-eigene Speicherlimit für CVE-2026-109618, ein darunterliegender Allokierungsfehler kann die Lücke aber weiterhin erreichen. ## Stolperfallen - **Die CLI ist nicht der Webserver.** `php -v` kann eine korrigierte Version zeigen, während ein älterer FPM-Pool aus einem anderen Paket weiter Requests bedient. Prüfen Sie jeden FPM-Dienst. - **ini\_set() und .user.ini wirken nicht als Abhilfe.** Laut Advisory muss die Einstellung für Session Upload Progress greifen, bevor der Request geparst wird, also gehört sie in die php.ini oder die Pool-Konfiguration. - **Fehler auszublenden hilft nicht.** Das Advisory schreibt, dass `display_errors`, `error_reporting` und der `@`\-Operator den Weg über Diagnosemeldungen nicht blockieren. Entfernen Sie die ungültigen oder veralteten Einstellungen pro Request, die ihn auslösen. - **PHP 8.2 läuft im Dezember aus.** Laut PHP-Projekt bekommt 8.2 nach dem 31. Dezember 2026 keine Sicherheitsfixes mehr. Wenn Sie heute 8.2 patchen, planen Sie jetzt den Wechsel auf 8.4 oder 8.5. **So wurde es geprüft.** Am 21. Oktober 2026 haben wir die Sicherheitsankündigung von PHP und die beiden GitHub-Advisories gelesen, dazu die Einträge im Debian-Security-Tracker für beide CVEs und Ubuntus CVE-Seite. Die Aktualisierungszeiten der Docker-Hub-Tags `php:8.5` und `php:8.4` haben wir über die Docker-Hub-API bestätigt. Nicht getestet: die Lücken selbst. Wir haben nicht versucht, sie nachzustellen. ## Quellen 1. [PHP News Archive 2026](https://www.php.net/archive/2026.php), PHP-Projekt, Sicherheitsankündigung und Release Notes, 21. Oktober 2026 2. [GHSA-w8hw-w9fx-j79w: RCE via OOM corruption](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w), php/php-src 3. [GHSA-6wmf-4rv5-p3rp: RCE via stale global state](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp), php/php-src 4. [CVE-2026-109618](https://security-tracker.debian.org/tracker/CVE-2026-109618) und [CVE-2026-109619](https://security-tracker.debian.org/tracker/CVE-2026-109619), Debian-Security-Tracker 5. [CVE-2026-109618](https://ubuntu.com/security/CVE-2026-109618), Ubuntu Security 6. [PHP Remote Code Execution FAQ](https://watchtowr.com/intelligence/php-cve-2026-109618-faq/), watchTowr ## Häufige Fragen ### Was ist PHP2Shell? PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP, veröffentlicht am 21. Oktober 2026. CVE-2026-109618 ist eine Remotecodeausführung über die Behandlung von Speichermangel, die Request-Daten halb initialisiert zurücklässt. CVE-2026-109619 ist eine Remotecodeausführung über globalen Zustand, der nach dem Freigeben seines Speichers bestehen bleibt und vom nächsten Request desselben Workers verwendet wird. Beide haben CVSS v4.0 9.2 und erfordern keine Anmeldung. ### Welche PHP-Versionen beheben CVE-2026-109618 und CVE-2026-109619? PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP 8.1 und älter erhalten keine Releases vom PHP-Projekt, das Sicherheitsteam hat aber minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht. Die Pakete der Distributionen enthalten den Fix unter eigenen Versionsnummern, etwa 8.4.27-1~deb13u1 unter Debian 13 und 8.3.6-0ubuntu0.24.04.13 unter Ubuntu 24.04. ### Kann ich PHP2Shell ohne Update entschärfen? Nur teilweise. Das PHP-Sicherheitsteam nennt Notlösungen wie session.upload\_progress.enabled=0, ein niedriges post\_max\_size und unter PHP 8.5 fatal\_error\_backtraces=0, schreibt aber, dass diese nur bestimmte Angriffswege blockieren und eine Installation nicht sicher machen. Nur das Update behebt das Problem vollständig. ### Muss ich PHP-FPM nach dem Update neu starten? Ja. Laufende FPM-Worker halten den alten Code im Speicher, bis sie neu starten. Starten Sie alle FPM-Dienste neu, laden Sie Apache neu, falls mod\_php läuft, und prüfen Sie die Version, die der Webserver meldet, nicht nur die der CLI. **Unsicher, welches PHP auf Ihren Servern läuft?** Die kostenlose Prüfung listet alle PHP-Versionen und Pools auf Ihren Servern und wie jede davon gepatcht wird. Die Prüfung läuft auf Englisch. [Preise (EN)](/pricing/). [Kostenlose Serverprüfung](/contact/)