php2shell (CVE-2026-109618 / 109619) lässt sich nicht mit php -v beurteilen: Wo die Versionsnummern bei FPM, Docker und Distributionen auseinanderlaufen

Ist das PHP, das Webanfragen verarbeitet (PHP-FPM, mod_php von Apache, php-cgi, FrankenPHP, LiteSpeed), älter als 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12, ist es von CVE-2026-109618 und CVE-2026-109619 betroffen, bekannt als php2shell. Abhilfe schafft das Upgrade auf eine dieser Versionen (bei Distributionspaketen: auf das korrigierte Paket) und ein Neustart der Prozesse. Zu prüfen ist nicht das lokale php -v, sondern „das PHP, das tatsächlich das Web bedient“, und „die installierte Paketversion“.

Dieser Artikel konzentriert sich auf vier Stellen, an denen eine Beurteilung allein nach der Versionsnummer zu falschen Schlüssen führt. Alle Zahlen und Statusangaben gelten mit Stand 2026-10-22; die Quellen zu den einzelnen Punkten stehen am Ende.

Was mit Stand 2026-10-22 bekannt ist

Das PHP-Advisory hält fest: „Die einzige vollständige Lösung ist das Update.“ Maßnahmen zur Überbrückung bis zum Update folgen weiter unten im Artikel.

Stolperfalle 1: php -v und das Web-PHP können verschiedene Versionen sein

Ein per SSH eingegebenes php -v zeigt die Version des CLI-PHP. Webanfragen werden von PHP-FPM-Prozessen oder von mod_php in Apache bearbeitet; das sind eigene Binaries und eigene Pakete. Wenn Sie ein neueres PHP nur für die CLI installiert haben, mehrere Versionen parallel betreiben oder ein FPM-Pool auf eine andere Version zeigt, kann die Webseite alt bleiben, auch wenn php -v eine korrigierte Version anzeigt.

Es gibt mehrere Wege, die tatsächliche Version auf der Webseite zu ermitteln.

# FPM unter Debian / Ubuntu (Name je nach Version)
php-fpm8.3 -v

# FPM auf RHEL-Systemen
php-fpm -v

# Prüfen, ob mod_php in Apache geladen ist
apachectl -M | grep -i php

Am zuverlässigsten lassen Sie das PHP, das tatsächlich über das Web läuft, seine eigene Version melden. Legen Sie eine temporäre Datei mit schwer zu erratendem Namen ab und löschen Sie sie sofort nach der Prüfung.

<?php echo PHP_VERSION, ' ', PHP_SAPI;

Ist PHP_SAPI gleich fpm-fcgi, läuft PHP unter FPM; apache2handler bedeutet mod_php; cgi-fcgi bedeutet CGI. Lassen Sie phpinfo() nicht erreichbar, denn das gibt für sich genommen schon Informationen preis.

Auch der Neustart wird leicht übersehen. Selbst wenn das Paket ersetzt wurde, können bereits laufende php-fpm- oder Apache-Prozesse weiter den alten Code ausführen. Manche Setups starten bei Paketupdates automatisch neu, andere nicht. Starten Sie nach dem Update FPM / Apache neu und prüfen Sie die Version auf der Webseite erneut mit den oben genannten Methoden.

Stolperfalle 2: Bei Docker lässt sich nicht am Tag-Namen urteilen

Das offizielle php-Image hat „bewegliche Tags“ wie 8.3 und 8.3-fpm, deren Inhalt ausgetauscht wird, und feste Tags wie 8.3.30, die die Version festlegen.

• Auch wenn ein beweglicher Tag auf Docker Hub auf eine korrigierte Version umgestellt wurde, bleibt Ihre lokale Kopie das alte Image, bis Sie erneut pullen. Laufende Container nutzen das alte Image ebenfalls weiter, bis sie neu erstellt werden. Ein Dockerfile mit FROM php:8.3-fpm baut weiterhin auf der alten Basis, wenn diese im Build-Cache liegt.
• Ein fester Tag bleibt für immer alt, bis Sie die Nummer selbst erhöhen.

Ob Tags mit korrigierten Versionen veröffentlicht wurden, lässt sich über die API von Docker Hub prüfen.

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

Hier die Ergebnisse einer Abfrage von vier Release-Linien am 2026-10-22 (Zeiten in UTC).

Dabei haben sich drei Punkte gezeigt, an denen eine Beurteilung nach Zahlen in die Irre führen kann.

1. „Kürzlich aktualisiert“ heißt nicht „korrigiert“. Der feste Tag 8.3.35 wurde im Lauf des 2026-10-21 neu gebaut, aber die PHP_VERSION darin war weiterhin 8.3.35. Sehen Sie auf die Version im Inneren, nicht auf den Aktualisierungszeitpunkt.
2. Unterschiedliche Digests können denselben Inhalt haben. 8.3 und 8.3.36 hatten unterschiedliche Tag-Digests (der Wert des Multi-Architektur-Index), aber das amd64-Image war identisch und beide hatten PHP_VERSION=8.3.36. Ebenso war bei 8.3-fpm / 8.3.36-fpm, 8.4-apache / 8.4.27-apache, latest / 8.5.12, 8.5-fpm und 8.2-fpm die PHP_VERSION des amd64-Images eine korrigierte Version.
3. Für 8.1 und älter gibt es keine korrigierten offiziellen Images. 8.1-fpm wurde zuletzt am 2025-12-31 aktualisiert.

So prüfen Sie lokale Images und laufende Container:

# PHP-Version eines lokal gepullten Images
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# Erneut pullen und die Container neu erstellen
docker compose pull
docker compose up -d

# Wenn Sie ein eigenes Image bauen: Basis neu pullen, dann bauen
docker compose build --pull

# Version in einem laufenden Container
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

Ersetzen Sie app im letzten Befehl durch den Namen Ihres eigenen Services. Jedes offizielle Image wird mit genau einer PHP_VERSION gebaut, daher entspricht die CLI-Version im Container der FPM-/Apache-Version dieses Containers (Stolperfalle 1 gilt, wenn PHP direkt auf dem Host installiert ist).

FrankenPHP bettet PHP ein, daher sind die FrankenPHP-Version und die eingebettete PHP-Version unterschiedliche Nummern. Die Release Notes zu FrankenPHP 1.13.2, veröffentlicht am 2026-10-21, besagen, dass die Docker-Images mit PHP 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 und die statischen Binaries mit PHP 8.5.12 gebaut wurden.

Stolperfalle 3: Distributionspakete sind „mit alter Nummer korrigiert“

Ubuntu und RHEL portieren nur die Korrekturen auf ältere Versionen zurück (Backporting). Die von php -v angezeigte Nummer bleibt alt; eine reine Zahlenprüfung wie „kleiner als 8.3.36, also verwundbar“ meldet daher ein korrigiertes System als verwundbar. Umgekehrt dürfen Sie sich auch nicht auf die Nummer verlassen, um beruhigt zu sein. Entscheiden Sie anhand der Paketversion und des Security-Trackers der jeweiligen Distribution.

Korrigierte Pakete laut den Trackern, Stand 2026-10-22 (für beide CVEs identisch):

Diese Tabelle zeigt unmittelbar, warum Nummern allein nicht genügen. Das korrigierte PHP von Ubuntu 24.04 ist eine Version, die mit 8.3.6 beginnt und damit weit unter der Upstream-Version 8.3.36 liegt. Das Standard-PHP von RHEL 9 ist korrigiert und bleibt dabei bei 8.0.30, obwohl Upstream für 8.0 keine Korrekturen mehr herausgibt. Debian ist auf dieselben Nummern wie Upstream umgestiegen (8.2.35 / 8.4.27).

Einige Pakete sind noch nicht korrigiert (Stand 2026-10-22).

• Das php-Modul 8.4 von RHEL 9 ist als „betroffen, keine Korrektur“ aufgeführt.
• Debian forky (testing) hat php8.4 8.4.26-1, markiert als „vulnerable“. Das php8.4 in sid (unstable) ist 8.4.27-1 und korrigiert.

Beispielbefehle zur Prüfung des eigenen Servers:

# Debian / Ubuntu: installierte und verfügbare Version
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu: ob diese CVE auf diesem Server behoben ist
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL-Familie: ob es ein Update gibt, das diese CVE behebt, und die installierte Version
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

Passen Sie den Paketnamen (php8.3-fpm usw.) an Ihre Umgebung an. Vergleichen Sie die angezeigte Version mit der „korrigierten Version“ in der obigen Tabelle oder im Tracker; ist sie gleich oder höher, ist die Korrektur enthalten. Führen Sie anschließend den in Stolperfalle 1 beschriebenen Neustart und die Prüfung auf der Webseite durch.

Wenn Sie PHP aus einem Drittanbieter-Repository statt aus den Paketen der Distribution installieren, müssen Sie die Updates dieses Repositorys verfolgen. Das PHP-Advisory weist darauf hin, dass das ehrenamtlich betriebene rpms.remirepo.net am Tag der Veröffentlichung keine Updates haben würde, und empfiehlt den Wechsel zu Distributionspaketen oder eigenen Builds.

Stolperfalle 4: Bei Shared Hosting und Managed-Umgebungen können Sie PHP nicht selbst aktualisieren

Bei Shared Hosting und verwalteten PHP-Umgebungen tauscht der Anbieter die PHP-Laufzeit aus. Auch hier genügt die Nummer allein nicht: Baut der Anbieter PHP selbst oder portiert er Korrekturen zurück, kann die Versionsnummer alt bleiben.

Drei Dinge können Sie selbst tun.

1. Die Version auf der Webseite prüfen. Geben Sie mit der temporären Datei aus Stolperfalle 1 PHP_VERSION und PHP_SAPI aus und löschen Sie sie sofort wieder. Bietet das Kontrollpanel eine Auswahl der PHP-Version, notieren Sie auch, welche Version Sie gewählt haben.
2. Die Mitteilung des Anbieters lesen und nachfragen, falls es keine gibt. Fragen Sie: „Für welche PHP-Versionen in meinem Tarif werden die Korrekturen für CVE-2026-109618 und CVE-2026-109619 wann angewendet (oder wurden sie bereits angewendet)?“ Wenn Sie nach der CVE-Nummer statt nach der Versionsnummer fragen, erhalten Sie eine Antwort, die auch Backports abdeckt.
3. Wenn Sie eine nicht mehr unterstützte Version gewählt haben, wechseln Sie. Das PHP-Projekt veröffentlicht für 8.1 und älter keine Korrekturen, und der Support für 8.2 endet am 2026-12-31. Sofern der Anbieter die Korrekturen nicht zurückportiert hat, ist der Versionswechsel der sichere Weg.

Stand bei den Hosting-Anbietern (Stand 2026-10-22)

Beim Shared Hosting aktualisiert normalerweise der Anbieter die PHP-Laufzeit, und viele Mitteilungen sagen, dass „keine Maßnahmen seitens der Nutzer erforderlich“ seien. Nutzer haben zwei Aufgaben: die offizielle Mitteilung ihres Anbieters prüfen und, falls sie im Kontrollpanel eine alte PHP-Version gewählt haben, entscheiden, ob sie auf die in der Mitteilung empfohlene Version (eine mit veröffentlichter Korrektur) wechseln.

Die folgende Tabelle fasst nur zusammen, was auf den offiziellen Seiten der Anbieter (Ankündigungen und Wartungsinformationen) steht, und gibt den Wortlaut der Mitteilungen sinngemäß wieder. Mitteilungen werden im Verlauf aktualisiert; prüfen Sie den tatsächlichen Stand daher immer auf der angegebenen offiziellen Seite.

Wo ich keine offizielle Mitteilung finden oder öffnen konnte, steht in der Tabelle „nicht bestätigt“ oder „nicht gefunden“. Fehlende Informationen bedeuten dort nicht, dass der Anbieter nicht reagiert hat. Prüfen Sie dies direkt in den Ankündigungen und beim Support Ihres Anbieters.

Schutzmaßnahmen, solange Sie nicht sofort aktualisieren können

Das PHP-Advisory nennt Einstellungen, die die Angriffsfläche bis zum Update verringern. Das Advisory selbst stellt jedoch ausdrücklich klar, dass sie Sie „nicht sicher machen“. Die wichtigsten:

• Für CVE-2026-109619: Setzen Sie session.upload_progress.enabled=0 in der php.ini, im FPM-Pool oder in der Serverkonfiguration und starten Sie alle Worker neu (ini_set() und die .user.ini von FPM wirken hier nicht). Setzen Sie unter PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Für CVE-2026-109618: Setzen Sie memory_limit=-1 so, dass die Anwendung es nicht überschreiben kann, und verringern Sie post_max_size (8M ohne Uploads, 32M mit Uploads). Verwenden Sie RLIMIT_AS / RLIMIT_DATA nicht als Ersatz.

Das britische NCSC empfiehlt, jedes System, das nicht sofort aktualisiert oder abgesichert werden kann, offline zu nehmen (zu erwägen), und vor dem Update oder der Absicherung auf Anzeichen einer Kompromittierung zu prüfen.

Quellen (geprüft am 2026-10-22)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: Release-Ankündigungen zu PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: offizielles php-Image
• Release Notes zu FrankenPHP 1.13.2
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu: CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat: CVE-2026-109618 / CVE-2026-109619 (Versionen der behobenen Pakete aus den VEX-Daten von Red Hat)
• NCSC: Critical security issue affecting PHP