PHP2Shell: QDE ist gepatcht. So aktualisierst du deine Server

Am 21. Oktober 2026 veröffentlichte PHP Notfallupdates für zwei kritische Schwachstellen: CVE-2026-109618 und CVE-2026-109619. Die unter dem Namen PHP2Shell bekannten Fehler können eine unauthentifizierte Remote-Code-Ausführung in der PHP-Laufzeitumgebung ermöglichen. PHP bewertet beide nach CVSS v4.0 mit 9.2.

QDE hat seine cPanel-Server für Shared Hosting, das Abrechnungssystem und das Kundenportal gepatcht. Kunden mit Shared Hosting müssen die PHP-Laufzeitumgebung nicht selbst aktualisieren. Wenn PHP auf einem VPS oder Dedicated Server von QDE läuft, verwaltest du das Betriebssystem selbst. Installiere deshalb das passende Update des jeweiligen Anbieters und starte sämtliche PHP-Worker neu.

Den Stand der Pakete und Sicherheitshinweise in dieser Anleitung haben wir am 27. Oktober 2026 geprüft.

Welche Installationen von PHP2Shell betroffen sind

Die Schwachstellen stecken in PHP selbst. Ein Update von WordPress, Laravel, Symfony oder einer anderen Anwendung repariert die darunterliegende Laufzeitumgebung nicht.

CVE-2026-109618 betrifft die Out-of-Memory-Behandlung von PHP. PHP kann die Vorbereitung einer Anfrage abbrechen, während interne Daten nur teilweise initialisiert sind. Die anschließende Bereinigung behandelt diesen ungültigen Zustand dann als verwendbar. Das PHP-Team hat eine Code-Ausführung über HTTP mit Apache mod_php nachgewiesen. Dort kann der anfällige Pfad bereits vor dem Start des Anwendungscodes ausgeführt werden. PHP-FPM gilt ebenfalls als betroffen. Die bestätigten Angriffspfade und ihre Zuverlässigkeit unterscheiden sich jedoch, weil ein FPM-Childprozess nach bestimmten Startfehlern beendet wird.

Bei CVE-2026-109619 bleiben an eine Anfrage gebundene Zustandsdaten erhalten, obwohl der dazugehörige Speicher bereits freigegeben wurde. Eine spätere Anfrage, die derselbe Worker verarbeitet, kann diesen zurückgebliebenen Zustand verwenden. Das PHP-Advisory beschreibt bestätigte Pfade zur Code-Ausführung für mod_php und PHP-FPM.

Ein erfolgreicher Angriff führt Code mit den Rechten des PHP-Workers aus. Dieses Konto kann in der Regel Anwendungsdateien und Secrets lesen, Datenbankverbindungen aufbauen und Webinhalte verändern, auch ohne Root-Zugriff. Das Update sollte deshalb umgehend installiert werden.

Exploitmaterial kursierte schon vor der koordinierten Veröffentlichung. AWS konnte einen Angriffsversuch bis zum 17. Oktober zurückverfolgen und fand mehrere Proofs of Concept, bevor das Embargo am 21. Oktober endete. Sowohl AWS als auch Cloudflare beobachteten Angriffsverkehr. Wie zuverlässig öffentlicher Exploitcode funktioniert, hängt vom PHP-Build, den Erweiterungen, dem Speicher-Allocator, dem Webserver und dem Verhalten der Anwendung ab. Installiere den im Hersteller-Advisory genannten Patch unabhängig davon, ob ein öffentlicher Proof of Concept auf deinem Build zuverlässig funktioniert. Systeme, die vor dem Patchen erreichbar waren, sollten außerdem auf Spuren eines Einbruchs geprüft werden.

Korrigierte PHP-Upstream-Releases

Diese Upstream-Releases enthalten erstmals die vollständigen Korrekturen:

Der Support für PHP 8.2 endet am 31. Dezember 2026. Plane daher auch nach der Installation von 8.2.35 den Wechsel auf einen unterstützten Versionszweig.

PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine regulären Releases mehr. PHP hat minimale Quellcode-Backports für 7.4, 8.0 und 8.1 veröffentlicht. Mehrere Anbieter von Betriebssystemen und Verwaltungspanels liefern zudem eigene Pakete mit Rückportierungen aus. Ein gepatchter Build kann deshalb weiterhin eine alte Upstream-Versionsnummer anzeigen. Prüfe die vollständige Paketrevision und das Advisory des Anbieters, anstatt dich nur auf php -v zu verlassen.

Ein separates Advisory vom 23. Oktober

Zwei Tage nach den PHP2Shell-Releases veröffentlichte PHP Informationen zu CVE-2026-115560. Dabei handelt es sich um ein separates Problem mit der Fortschrittsanzeige für Session-Uploads. Die oben aufgeführten Releases vom 21. Oktober beheben es nicht. Für einen Angriff muss eine ungewöhnliche Kombination vorliegen: Der Upload-Fortschritt ist aktiviert, session.serialize_handler beginnt mit php_binary oder php_serialize und der Anwendungscode ändert den Wert vor dem Aufruf von session_start() auf php.

PHP will CVE-2026-115560 mit dem nächsten regulären Bugfix-Release beheben. Bis zur Installation dieses Releases empfiehlt PHP die Einstellung session.upload_progress.enabled=0. Setze sie in der Startkonfiguration und starte alle Worker neu. Anwendungen, die den Serialisierungs-Handler zur Laufzeit nie ändern, sind von diesem separaten Problem nicht betroffen.

Was QDE gepatcht hat

QDE hat die Korrekturen für CVE-2026-109618 und CVE-2026-109619 auf den von uns verwalteten Systemen installiert:

• cPanel-Server für Shared Hosting und die dort angebotenen PHP-Versionen;
• das Abrechnungssystem von QDE;
• das Kundenportal von QDE.

Liegt deine Website auf QDE Shared Hosting, musst du für diese beiden PHP2Shell-Korrekturen nichts unternehmen. Halte dein CMS, Plug-ins, Themes und Anwendungsabhängigkeiten trotzdem aktuell, da sie unabhängig von PHP2Shell gepflegt werden müssen.

Die VPS- und Dedicated-Server-Angebote von QDE sind unmanaged. Wir verwalten die physische Infrastruktur, das Netzwerk und die Virtualisierungsschicht. Für die Pakete innerhalb deines Servers bist du selbst zuständig. Folge dem passenden Abschnitt unten und öffne ein Support-Ticket, wenn du nicht sicher bist, welche Paketquelle dein Server verwendet.

Vor dem Update

Prüfe vor einem Wechsel der Repositorys oder Release-Streams, wie PHP installiert wurde:

php -v
command -v php

# Debian or Ubuntu
apt-cache policy php php8.2-cli php8.3-cli php8.4-cli php8.5-cli

# RHEL, AlmaLinux, Rocky Linux, or CentOS Stream
dnf module list php
rpm -qf "$(command -v php)"

Erstelle eine aktuelle Sicherung oder einen Snapshot, besonders vor dem Wechsel des PHP-Versionszweigs. Ein Update innerhalb des vorhandenen Distributionszweigs verursacht normalerweise die wenigsten Probleme. Beim Wechsel von PHP 8.2 auf 8.4 oder 8.5 können Inkompatibilitäten mit Anwendungen und Erweiterungen sichtbar werden. Verbinde den Sicherheitspatch daher nur dann mit einem solchen Wechsel, wenn deine bisherige Quelle kein korrigiertes Paket anbietet.

Debian 12 oder Debian 13 patchen

Debian hat für beide unterstützten Releases korrigierte Pakete veröffentlicht. DLA-4848-1 behebt die Fehler in den php8.2-Paketen von Debian 12 mit 8.2.35-1~deb12u1. DSA-6574-1 korrigiert die php8.4-Pakete von Debian 13 mit 8.4.27-1~deb13u1.

Wenn du die Debian-Pakete verwendest, prüfe zunächst, ob das Sicherheits-Repository aktiviert ist. Sieh dir anschließend die vorgesehenen Änderungen an und installiere das Update:

sudo apt update
apt list --upgradable
sudo apt upgrade

Debian behält den mit dem jeweiligen Release ausgelieferten PHP-Zweig bei. Für diesen Patch musst du daher kein Repository eines Drittanbieters hinzufügen.

Verwendet dein Server bereits das PHP-Repository von Ondřej Surý, installieren dieselben Updatebefehle den korrigierten Build für den ausgewählten Zweig. Füge das Repository keiner funktionierenden Debian-Installation hinzu, nur um die von php -v ausgegebene Nummer zu erhöhen.

Debian 11 patchen

Der LTS-Support für Debian 11 endete am 31. August 2026. Debian wird für seine PHP-7.4-Pakete kein PHP2Shell-Update veröffentlichen. Ein Upgrade des Betriebssystems ist die dauerhafte Lösung.

Wenn du für die Vorbereitung dieses Upgrades etwas Zeit brauchst, ist ein unterstützter kommerzieller Dienst mit verlängerter Lebenszykluspflege die sicherere Zwischenlösung. Das öffentliche Repository von Ondřej Surý veröffentlichte bei unserer Prüfung noch Bullseye-Pakete. Der PHP-7.4-Build 1:7.4.33-31+0~20261021.121+debian11~1.gbpe9c428 enthält den PHP2Shell-Backport. Damit wechselst du die Paketquelle auf einem Betriebssystem, dessen regulärer Support bereits beendet ist. Teste die Änderung und plane das Debian-Upgrade weiter ein; das Paket macht Bullseye nicht wieder zu einer unterstützten Plattform.

Die offiziellen Bullseye-Repositorys enthalten keinen PHP2Shell-Patch. Ihr Ende der LTS-Phase erfordert für sich genommen keine Änderung der Adressen. Wenn du den öffentlichen Sury-Build vorübergehend verwenden möchtest, füge das Repository nach der veröffentlichten Anleitung hinzu:

sudo apt update
sudo apt install lsb-release ca-certificates curl
sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb https://packages.sury.org/debsuryorg-archive-keyring.deb
sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb
sudo sh -c 'echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] https://packages.sury.org/php/ bullseye main" > /etc/apt/sources.list.d/php.list'
sudo apt update
apt list --upgradable
sudo apt upgrade

Lies den Paketplan, bevor du ihn bestätigst. Ist das unversionierte Metapaket php installiert, kann es neben der derzeit von deiner Anwendung verwendeten Version auch einen neueren PHP-Zweig auswählen.

Ubuntu patchen

Das Ubuntu-Advisory USN-8948-1 stellt korrigierte Herstellerpakete für Ubuntu 22.04 LTS, 24.04 LTS, 26.04 LTS und 26.10 bereit. Wenn du die PHP-Pakete von Ubuntu verwendest, führe Folgendes aus:

sudo apt update
apt list --upgradable
sudo apt upgrade

Ubuntu spielt die Korrekturen als Backports ein. Der Upstream-Anteil der Versionsnummer kann daher unter 8.2.35, 8.3.36 oder 8.5.12 bleiben. Vergleiche die vollständige installierte Paketversion mit USN-8948-1.

Wenn du bereits das PPA von Ondřej Surý nutzt, installiere das Update auf dieselbe Weise aus dieser Quelle. Das PPA unterstützt aktuelle Ubuntu-LTS-Releases, jedoch keine Versionen, die in die Expanded Security Maintenance übergegangen sind.

Canonical hat ein separates Ubuntu-Pro/ESM-Update für Ubuntu 20.04 veröffentlicht. Es enthält unter anderem das PHP-7.4-Paket 7.4.3-4ubuntu2.29+esm5. Systeme mit Ubuntu 20.04 und aktiviertem passendem Ubuntu-Pro-Dienst können dieses Herstellerupdate installieren. Ohne diesen Dienst solltest du das Betriebssystem aktualisieren, statt ein nicht unterstütztes PPA hinzuzufügen.

RHEL, AlmaLinux, Rocky Linux oder CentOS Stream patchen

Red Hat, AlmaLinux und Rocky Linux liefern die PHP-Korrekturen als Backports unter eigenen Paketrevisionen aus. Das PHP2Shell-Sicherheitsbulletin von Red Hat, die Errata von AlmaLinux und die Errata von Rocky Linux führen die betroffenen Streams auf.

Für die Standardpakete der Distribution:

sudo dnf upgrade --refresh

Prüfe auf der CVE-Seite des Anbieters deine genaue Hauptversion und den Modulstream. Die Bearbeitung durch Red Hat war bei unserer Prüfung noch als 'Ongoing' markiert. Für einige Streams standen Updates bereit, für andere liefen die Arbeiten noch. Red Hat veröffentlicht außerdem getrennte Errata für Standard-Support, Extended Update Support und weitere Lebenszyklus-Streams. Eine in einem Kanal korrigierte Version belegt daher nicht die Verfügbarkeit in allen anderen Kanälen.

Verwendet dein Server bereits das Repository von Remi, installiert dnf upgrade --refresh das korrigierte Paket für den aktivierten Stream. Musst du den Stream wechseln, nutze Remis Konfigurationsassistenten und teste die Anwendung vorher. dnf module switch-to ändert die installierten Pakete und den aktivierten Stream. Es handelt sich um eine Migration und nicht um ein gewöhnliches Sicherheitsupdate.

Einen selbst verwalteten cPanel-Server patchen

cPanel hat korrigierte EasyApache-4-Pakete für PHP 7.4 bis 8.5 sowie aktualisierte interne PHP-Pakete für cPanel und Roundcube veröffentlicht. Das PHP2Shell-Advisory von cPanel nennt die genauen Paketrevisionen.

Aktualisiere die Paketmetadaten und lasse cPanel die von ihm verwalteten Pakete einspielen:

# RHEL-family cPanel servers
sudo yum clean all
sudo yum makecache

# Ubuntu cPanel servers
sudo apt clean
sudo apt update

# Both platforms
sudo /scripts/update-packages

Auf einem RPM-basierten cPanel-Server kannst du so prüfen, ob ein bestimmtes EasyApache-PHP-Paket die Korrektur enthält:

rpm -q --changelog ea-php81-php-cli | grep -m1 CVE-2026-109618

Ersetze php81 durch jeden installierten PHP-Zweig. Ein Update nur der internen PHP-Version von cPanel reicht nicht aus, wenn EasyApache PHP weiterhin Websites aus einem älteren Paket bedient.

PHP in Containern patchen

Ein Update des Hosts ersetzt PHP innerhalb eines Containers nicht. Lade ein Basis-Image mit einem korrigierten Upstream-Release oder einem dokumentierten Hersteller-Backport herunter, oder baue dein Image damit neu. Erstelle anschließend die laufenden Container neu:

docker compose pull
docker compose build --pull --no-cache
docker compose up -d --force-recreate

Führe nur die Befehle aus, die zu deiner Bereitstellung passen. Ein Stack, der ein veröffentlichtes Image bezieht, benötigt in der Regel pull. Bei einem Stack mit eigener Dockerfile ist build --pull erforderlich. Kubernetes und andere Orchestratoren benötigen einen neuen Image-Digest und anschließend einen Rollout. Prüfe das Paket innerhalb des neuen Containers und nicht auf dem Host.

PHP nach dem Update neu starten

Laufende PHP-Worker haben die alte ausführbare Datei noch in den Speicher eingebunden. Starte nach dem Paketupdate PHP-FPM neu, bei geladenem mod_php auch Apache, oder ersetze den betreffenden Container beziehungsweise Pod. Ein reiner Konfigurations-Reload reicht bei diesem Vorfall nicht aus.

# Debian and Ubuntu: use the branch you actually run
sudo systemctl restart php8.2-fpm
sudo systemctl restart php8.3-fpm
sudo systemctl restart php8.4-fpm
sudo systemctl restart php8.5-fpm

# Apache with mod_php on Debian or Ubuntu
sudo systemctl restart apache2

# RHEL family
sudo systemctl restart php-fpm
sudo systemctl restart httpd

Starte nur Dienste neu, die auf deinem Server installiert sind. Wenn mehrere FPM-Zweige verschiedene Websites bedienen, musst du jeden aktiven Zweig neu starten.

Das Paket und jede Web-Laufzeitumgebung prüfen

php -v zeigt die CLI-Binärdatei an, die deine Shell findet. Ein separater FPM-Zweig, ein cPanel-EasyApache-Build oder PHP in einem Container kann dabei unentdeckt bleiben. Prüfe alle installierten Pakete:

# Debian and Ubuntu
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 2>/dev/null | sort

# RHEL family
rpm -qa 'php*' | sort

# Active FPM services on systemd distributions
systemctl list-units --type=service --state=running 'php*-fpm.service'

Vergleiche das Ergebnis mit dem Advisory deiner Distribution oder deines Verwaltungspanels. Bei einem Upstream-Build muss mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 installiert sein. Bei einem Backport sind die Paketrevision und das Changelog des Anbieters maßgeblich.

Prüfe außerdem, wohin jede Website ihre PHP-Anfragen sendet. Häufig wird nur die Standard-CLI-Binärdatei gepatcht, während ein älterer FPM-Pool, Container oder ein Paket des Verwaltungspanels weiterhin Webverkehr verarbeitet.

Vor dem Patch erreichbare Systeme prüfen

Das Update verhindert eine künftige Ausnutzung dieser Schwachstellen, kann einen früheren Einbruch aber nicht rückgängig machen. AWS hat einen Angriffsversuch bis zum 17. Oktober zurückverfolgt. Prüfe daher mindestens ab diesem Datum die Webserver- und PHP-Protokolle, wenn der Dienst im verwundbaren Zustand über das Internet erreichbar war.

Achte auf ungewöhnliche Multipart-Anfragen, unerwartete Childprozesse eines PHP-Workers, neue oder veränderte Dateien in Webroots und temporären Verzeichnissen, unbekannte geplante Aufgaben sowie Änderungen an Konten oder SSH-Schlüsseln. Die Angreifer passten ihre Payloads nach der Veröffentlichung schnell an. Eine erfolglose Suche nach einem einzigen öffentlichen Proof of Concept belegt deshalb kein sauberes System.

Findest du glaubwürdige Hinweise auf einen Einbruch, isoliere den Server und sichere die benötigten Beweise. Setze das System aus einem vertrauenswürdigen Image oder Backup neu auf. Ändere außerdem alle Zugangsdaten und Anwendungsgeheimnisse, die der PHP-Worker lesen konnte, darunter Datenbankpasswörter und API-Schlüssel.

Wenn du nicht sofort patchen kannst

Nimm den PHP-Dienst nach Möglichkeit vorübergehend aus dem öffentlichen Internet. Laut PHP ist das Update die einzige vollständige Lösung für die beiden ursprünglichen CVEs.

Das Upstream-Advisory nennt mehrere Teilmaßnahmen. Das Abschalten von session.upload_progress blockiert bestätigte sitzungsbezogene Angriffspfade für CVE-2026-109619 und schützt vor CVE-2026-115560. Unter PHP 8.5 lässt sich mit fatal_error_backtraces ein bestätigter Auslöser blockieren. Bei CVE-2026-109618 beseitigt ein administrativ erzwungenes memory_limit=-1 den vorhersagbaren Fehler am Speicherlimit, den der bestätigte Exploit verwendet. Andere Allokationsfehler bleiben möglich, und eine einzelne Anfrage kann den gesamten verfügbaren Speicher belegen. Verwende diese Einstellung deshalb nur mit einem sorgfältig eingerichteten Cgroup- oder Container-Limit und konservativen Limits für die Anfragegröße.

Diese Einstellungen können die Fortschrittsanzeige bei Uploads, die Fehlersuche, große Uploads oder Speichergrenzen beeinträchtigen. Setze sie über php.ini, einen FPM-Pool oder eine Serverkonfiguration, die vor der Verarbeitung der Anfrage greift. Starte danach die Worker neu. Eine WAF-Regel oder einzelne Konfigurationsänderung ersetzt den Patch nicht.

Update abschließen

Installiere das korrigierte Paket aus der Paketquelle, der dein Server bereits vertraut. Starte sämtliche PHP-Worker neu und prüfe für jede PHP-Laufzeitumgebung mit Webverkehr die vollständige Paketrevision.

Die PHP-Laufzeitumgebungen für QDE Shared Hosting sind bereits aktualisiert. Kunden mit einem VPS oder Dedicated Server von QDE müssen ihr Betriebssystem, ihre Container und Verwaltungspanels selbst aktualisieren. Wenn du bei der Paketquelle oder Dienststruktur deines Servers unsicher bist, öffne ein Ticket, bevor du Repositorys änderst.

Häufig gestellte Fragen zu PHP2Shell

Behebt ein Update von WordPress oder einer anderen PHP-Anwendung PHP2Shell?

Nein. Der verwundbare Code steckt in der PHP-Laufzeitumgebung. Aktualisiere das PHP-Paket des Betriebssystems, Containers oder Verwaltungspanels, auch wenn die Anwendung selbst aktuell ist.

Ist PHP-FPM betroffen?

Ja. PHP führt PHP-FPM unter den gefährdeten Serverschnittstellen auf. Das Advisory zum zurückgebliebenen Zustand dokumentiert außerdem einen bestätigten RCE-Pfad im Session-Lebenszyklus von FPM. Bestimmtes Startverhalten erschwert die Ausnutzung des nachgewiesenen Out-of-Memory-Pfads bei FPM gegenüber mod_php. Eine ungepatchte FPM-Installation ist trotzdem nicht sicher.

Reicht php -v zur Prüfung des Patches aus?

Nur bei einer einfachen Upstream-Installation, in der CLI und Webserver dieselbe Binärdatei verwenden. Backports einer Distribution können eine ältere Upstream-Nummer beibehalten. Ein Server kann außerdem mehrere FPM-Zweige oder Container-Images ausführen. Prüfe die Paketrevisionen und jede Laufzeitumgebung, die Webanfragen verarbeitet.

Müssen Kunden mit einem QDE VPS selbst aktualisieren?

Ja, wenn auf dem VPS PHP läuft. QDE VPS-Hosting ist unmanaged, deshalb verwalten Kunden das Gastbetriebssystem und seine Updates selbst. Patches an der QDE-Infrastruktur ersetzen keine Pakete innerhalb der virtuellen Maschine eines Kunden.

Müssen Kunden mit QDE Shared Hosting PHP aktualisieren?

Nein. QDE hat die PHP-Laufzeitumgebungen auf seinen Shared-Hosting-Servern bereits gepatcht. Kunden bleiben für Updates ihrer Websites, Plug-ins, Themes und Anwendungsabhängigkeiten selbst verantwortlich.