Wenn deine Website mit PHP läuft, solltest du den aktuellen Patchstand prüfen: CVE-2026-109618 und CVE-2026-109619 können eine Codeausführung ohne vorherige Anmeldung ermöglichen. Die beiden als PHP2Shell bezeichneten Lücken sitzen in PHP selbst. Ein gepflegtes CMS allein reicht deshalb nicht.

Stand: 23. Oktober 2026. Dieser Beitrag behandelt die beiden am 21. Oktober veröffentlichten kritischen PHP-Lücken. Er erklärt die technischen Hintergründe, korrigierte Versionen und die Prüfung von Website-PHP, Betriebssystempaketen und Plesk. Die genannten Mindeststände beheben diese beiden CVEs; sie sind kein allgemeines Sicherheitszertifikat für einen Server.

Kurzlösung

  1. Ermittle die PHP-Laufzeit jeder betroffenen Website und Anwendung. Die Shell-Ausgabe von php -v allein reicht dafür nicht.
  2. Installiere einen korrigierten Stand: PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 – beziehungsweise einen ausdrücklich bestätigten Hersteller-Backport.
  3. Bei Plesk zusätzlich das Panel aktualisieren: Die Korrektur der internen PHP-Engine steckt in 18.0.81 Update 4 beziehungsweise 18.0.80 Update 11.
  4. Stelle sicher, dass betroffene Worker und Dienste den neuen Code verwenden. Prüfe danach Laufzeit, Funktionen und Protokolle.
  5. Ist ein zeitnaher Patch nicht möglich, bewerte mit dem Betreiber eine vorübergehende Einschränkung oder Isolation. Konfigurationsänderungen ersetzen das Update nicht.

Direkt mit der Bestandsaufnahme beginnen

Wie kritisch sind die PHP-Sicherheitslücken?

CERT-EU bewertet beide Schwachstellen mit CVSS 4.0: 9,2 – kritisch und empfiehlt unverzügliches Patchen. Der veröffentlichte Sicherheitshinweis 2026-018 beschreibt mögliche Codeausführung ohne Anmeldung und öffentlich diskutierte technische Details. Ein verfügbarer Proof of Concept ist allerdings nicht gleichbedeutend mit dem Nachweis, dass jeder erreichbare Server bereits kompromittiert wurde.

Codeausführung bedeutet zunächst Ausführung mit den Rechten der betroffenen PHP-Anwendung. Das ist nicht automatisch Root-Zugriff. Trotzdem können bereits diese Rechte für den Zugriff auf Anwendungsdateien, Datenbankzugänge oder andere erreichbare Geheimnisse ausreichen. Die tatsächliche Auswirkung hängt unter anderem von Benutzertrennung und Berechtigungen ab.

Laut PHP-Projekt müssen alle PHP-Installationen berücksichtigt werden, die Webanfragen verarbeiten: PHP-FPM, Apache mit mod_php, CGI, FrankenPHP und LiteSpeed. Das Projekt sieht das höchste Risiko bei mod_php, wo ein demonstrierter Angriff schon vor dem eigentlichen Anwendungscode ansetzen kann. Ein Wechsel auf FPM ist deshalb kein Ersatz für einen Patch.

Was technisch schiefläuft

CVE-2026-109618: beschädigter Zustand bei Speichermangel

PHP begrenzt den Speicherverbrauch einzelner Anfragen normalerweise über memory_limit. Nach dem offiziellen Advisory zu CVE-2026-109618 kann ein Abbruch wegen Speichermangels interne Daten in einem nur teilweise initialisierten Zustand zurücklassen. Beim anschließenden Aufräumen kann PHP diese Daten fälschlich als gültig behandeln. Daraus kann eine Speicherbeschädigung bis hin zur Codeausführung entstehen.

Es geht also nicht bloß darum, dass eine große Datei einen Fehler verursacht. Entscheidend ist der fehlerhafte Umgang mit dem Abbruch. Bei FPM unterscheidet sich der Ablauf vom Apache-Modul; das Advisory stuft FPM dennoch als anfällig ein. Die konkrete Erreichbarkeit eines Angriffspfads hängt von Laufzeit und Anwendung ab.

CVE-2026-109619: veraltete Verweise zwischen Anfragen

Ein PHP-Worker bearbeitet häufig mehrere Anfragen nacheinander. Dabei darf interner Zustand nicht mehr auf Speicher einer bereits beendeten Anfrage zeigen. Genau das kann laut Advisory zu CVE-2026-109619 schiefgehen: Eine spätere Anfrage greift auf bereits freigegebenen Speicher zu.

Für einen erfolgreichen Angriff müssen zusammenpassende Abläufe denselben Worker erreichen: Ein Vorgang hinterlässt den veralteten Zustand, ein weiterer verwendet ihn. Das erklärt, warum eine Versionsnummer allein nicht vorhersagt, wie leicht eine bestimmte Installation angreifbar ist. Es rechtfertigt aber nicht, einen bestätigten Patch aufzuschieben.

Welche PHP-Versionen enthalten die Korrektur?

Für die regulären PHP-Veröffentlichungen gelten die folgenden Mindeststände. Die Zuordnung ist in den PHP-Advisories und im PHP-Changelog dokumentiert:

PHP-ZweigUngepatchte Upstream-VersionenKorrektur enthalten ab
8.2vor 8.2.358.2.35
8.3vor 8.3.368.3.36
8.4vor 8.4.278.4.27
8.5vor 8.5.128.5.12

Die Tabelle gilt nicht als pauschaler Vergleich für beliebige Distributionspakete. Ein Anbieter kann die Korrektur in einen älteren Versionszweig zurückportieren. Dann ist die vollständige Paketrevision samt Herstellerhinweis entscheidend.

Sonderfall: alte PHP-Zweige

PHP 8.1 und ältere Zweige erhalten vom PHP-Projekt keine regulären Updates mehr. Einzelne Distributoren oder Anbieter liefern eigene Backports. Prüfe deren konkrete Zusage für beide CVEs. Ein solcher Einzelpatch ersetzt keine belastbare Wartungsperspektive; eine Migration auf einen unterstützten Zweig bleibt ein eigenes Arbeitspaket. Maßgeblich sind die PHP-Supportübersicht und der Support deines Paketlieferanten.

Alle relevanten Laufzeiten erfassen

Beginne mit einer Liste der Websites und Anwendungen, nicht mit einem einzelnen Versionsbefehl. Halte pro Eintrag Domain, Betreiber, PHP-Zweig, Paketquelle und Betriebsart fest. Berücksichtige auch Staging, Subdomains, Webmail, Verwaltungsoberflächen und gegebenenfalls eingebettete PHP-Laufzeiten. CERT-EU weist ausdrücklich darauf hin, dass Produkte PHP intern mitbringen können.

Die Standardlaufzeit der Shell prüfst du mit diesen lesenden Befehlen:

Terminal
php -v
php --ini

-v zeigt die Version, --ini die Konfigurationsdateien dieser CLI-Laufzeit. Die Optionen sind im PHP-Handbuch dokumentiert. Eine Website kann jedoch einen anderen Interpreter und andere Einstellungen verwenden. Ein frisches CLI-PHP sagt nichts Verbindliches über den FPM-Pool einer anderen Domain aus.

Bei WordPress findest du Hinweise im Backend unter Werkzeuge → Website-Zustand → Bericht → Server. Dort lassen sich die von WordPress verwendete PHP-Version und die Serverumgebung prüfen. Die WordPress-Dokumentation zum Website-Zustand beschreibt diese Informationsansicht.

Nutze vorhandene geschützte Verwaltungsansichten. Eine dauerhaft öffentliche phpinfo()-Datei ist für die Bestandsaufnahme unnötig und kann zusätzliche Konfigurationsdetails offenlegen. Auch ein HTTP-Header allein ist kein belastbarer Patchnachweis.

Paketrevisionen und Hersteller-Backports richtig einordnen

Ein gutes Beispiel liefert Ubuntu USN-8948-1: Für Ubuntu 24.04 LTS ist die Korrektur bereits im Paket 8.3.6-0ubuntu0.24.04.13 enthalten. Für Ubuntu 22.04 LTS nennt Ubuntu 8.1.2-1ubuntu2.28. Beide sehen nach der reinen PHP-Versionsnummer älter aus als die Upstream-Tabelle. Trotzdem sind genau diese Herstellerpakete für die beiden Lücken korrigiert.

BeispielplattformOffiziell genannter korrigierter Paketstand
Ubuntu 24.04 LTS, Distributions-PHP 8.38.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS, Distributions-PHP 8.18.1.2-1ubuntu2.28
Debian 13 „trixie“, PHP 8.48.4.27-1~deb13u1

Den Debian-Stand bestätigt DSA-6574-1. Verwende solche Beispiele nur für die jeweils genannte Distribution und Paketquelle. Ein Ubuntu-Patch korrigiert nicht automatisch parallel installierte Plesk-Pakete oder den Inhalt eines Containers.

Für Plesk unter Linux nennt der Herstellerhinweis außerdem Backports für PHP 7.4.33, 8.0.30 und 8.1.34. Hier blieb die Versionsnummer gleich; die am 21. Oktober 2026 gebauten Pakete enthalten die Korrektur. „7.4.33 installiert“ reicht deshalb weder als Entwarnung noch als eindeutiger Nachweis eines ungepatchten Pakets.

Dokumentiere Paketquelle, vollständigen Paketstand und die zugehörige Bestätigung für beide CVEs. Wenn dein Hoster einen eigenen Build verwendet, muss er dessen Patchstatus belegen können.

Den passenden Updateweg verwenden

Auf einem betreuten Webhostingpaket ist der Anbieter für das Einspielen der Laufzeitpakete zuständig. Frage konkret nach beiden CVEs, dem eingesetzten Paketstand und der Aktivierung des Patches für deine Domain. „Unsere Server sind aktuell“ ist weniger aussagekräftig als eine nachvollziehbare technische Bestätigung.

Auf einem selbst verwalteten Ubuntu-System mit Distributionspaketen empfiehlt Ubuntu das Aktualisieren der Pakete. In einer administrativen Shell kannst du den normalen Ablauf getrennt ausführen:

Terminal
sudo apt update
sudo apt upgrade

Prüfe die vorgeschlagenen Änderungen vor der Bestätigung. Der zweite Befehl aktualisiert auch andere angebotene Pakete. Bei festgehaltenen Paketen, einer fehlgeschlagenen Paketinstallation oder einer falschen Paketquelle ist der Vorgang noch nicht abgeschlossen. Ein Paketdownload ist schließlich kein Sicherheitszustand.

Der Ubuntu-Herstellerhinweis betont außerdem, dass die betroffenen Anwendungen anschließend gegebenenfalls neu gestartet werden müssen. Bei Distributions-PHP mit Apache-Modul ist Apache zu berücksichtigen; bei FPM die tatsächlich verwendeten Worker.

Plesk-Pakete, Container und selbst gebaute Laufzeiten brauchen ihren jeweiligen Updateweg. Bei einem Container muss die korrigierte Laufzeit im neu bereitgestellten Image stecken. Für einen unterstützten PHP-Zweig reicht grundsätzlich dessen korrigierter Patchstand; ein ungeprüfter Wechsel des gesamten Projekts auf einen anderen Zweig ist keine notwendige Sofortmaßnahme.

Bei Plesk Website-PHP und Panel getrennt prüfen

Plesk verwaltet PHP-Versionen für Websites und verwendet zusätzlich eine eigene Engine für das Panel. Deshalb gibt es zwei getrennte Prüfpunkte. Nur die Domains auf PHP 8.4.27 zu bringen, sagt noch nichts über den Patchstand der internen Engine aus.

Prüfe zunächst unter Tools & Einstellungen → PHP-Einstellungen die verfügbaren Laufzeiten und je Domain die zugewiesene Version. Per administrativem SSH-Zugang liest du die registrierten Handler aus:

Terminal
plesk bin php_handler --list

Die Plesk-CLI-Dokumentation beschreibt auch die Zuordnung von Domains zu einem konkreten Handler. Ersetze die folgende Beispiel-ID durch eine tatsächlich vorhandene ID aus deiner Liste:

Terminal
plesk bin php_handler --get-usage -id plesk-php84-fpm

Eine bestimmte Plesk-Laufzeit kannst du beispielsweise so direkt abfragen; passe den Pfad an die installierte Version an:

Terminal
/opt/plesk/php/8.4/bin/php -v

Dieser Pfad prüft das betreffende CLI-Binary, nicht automatisch jeden Webprozess. Gleiche ihn mit der Domainzuordnung und dem Website-Bericht ab. Notiere auch geplante Aufgaben, die noch einen anderen PHP-Pfad verwenden.

Für die interne Engine nennt Plesk 18.0.81 Update 4 und 18.0.80 Update 11 als korrigierte Stände. Laut offiziellem Changelog vom 21. Oktober 2026 wurden sw-engine beziehungsweise plesk-engine dabei auf PHP 8.4.27 aktualisiert. Der Micro-Update-Stand gehört also zur Prüfung.

Plesk beschreibt den Updateweg über Tools & Einstellungen → Updates → Komponenten aktualisieren. Alternativ lautet der dokumentierte administrative CLI-Befehl:

Terminal
plesk installer update

Plane mögliche Dienstneustarts ein und prüfe das Ergebnis des Installers. Den Panelstand kannst du mit plesk version und der Systemübersicht abgleichen. Grundlage ist die Plesk-Updateanleitung; bei älteren Panelzweigen prüfst du den dafür vorgesehenen unterstützten Upgradeweg.

Neue Worker und die Website-Funktion kontrollieren

Nach der Installation müssen die tatsächlich verwendeten Dienste den korrigierten Code geladen haben. Prüfe zunächst, welche Neustarts der Paketmanager oder Installer bereits durchgeführt hat. Starte verbleibende betroffene Dienste kontrolliert neu, statt pauschal jeden PHP-Dienst zu stoppen.

Bei Plesk kannst du unter Tools & Einstellungen → Diensteverwaltung den benötigten PHP-Dienst neu starten; Plesk beschreibt das in seiner Neustartanleitung. Berücksichtige dabei dedizierte FPM-Pools und deren abweichende Verwaltung. Ein Handlername ist nicht zwingend ein direkt verwendbarer systemd-Dienstname.

Prüfe anschließend dieselbe Website erneut über ihren tatsächlichen Webzugriff. Bei mehreren Servern oder Loadbalancern muss jeder beteiligte Knoten berücksichtigt werden. Ein erfolgreicher Test auf einem Server deckt die anderen nicht mit ab.

  • Stimmen Domainzuordnung, Paketstand und Laufzeit nach dem Update überein?
  • Funktionieren Frontend und Anmeldung?
  • Funktionieren ein zulässiger Datei-Upload und wichtige Formulare?
  • Laufen anwendungsspezifische Aufgaben wie Shopabläufe, Webmail oder Cronjobs weiterhin?
  • Zeigen Webserver- und PHP-Protokolle seit dem Update neue Fehler?

Verwende dafür normale Anwendungsfunktionen. Ein fremdes Exploit-Skript auf dem Produktivserver ist kein erforderlicher Funktionstest.

Wenn du noch nicht patchen kannst

Die offiziellen Hinweise nennen Maßnahmen, die einzelne Angriffswege erschweren. Sie nennen aber keine vollständige Konfigurationslösung. CERT-EU empfiehlt, bei nicht zeitnah patchbaren internetzugänglichen Anwendungen eine vorübergehende Isolation zu erwägen. Das muss zum Dienst und zu seiner Erreichbarkeit passen.

Das PHP-Projekt beschreibt unter anderem session.upload_progress.enabled=0 mit Neustart aller Worker sowie zusätzliche Maßnahmen für bestimmte Abläufe. Diese Einstellung blockiert bestätigte Session-Pfade, nicht sämtliche Varianten. Eine Änderung mit ini_set() im Anwendungscode oder allein in einer FPM-.user.ini ist hierfür nicht gleichwertig.

memory_limit=-1 nicht blind übernehmen

Das Abschalten des PHP-Speicherlimits wird als begrenzte Maßnahme gegen einen bestimmten Fehlerpfad genannt. Es beseitigt jedoch nicht alle Auslöser und entfernt eine Speichergrenze. Übernimm das nicht pauschal auf einem produktiven Mehrkundensystem. Wenn eine Überbrückung nötig ist, muss sie samt Ressourcenbegrenzung zum Aufbau des Servers passen.

Die PHP-Sicherheitshinweise und die beiden technischen Advisories erklären die Grenzen. Sobald ein korrigiertes Paket verfügbar ist, sollte die Arbeit in dessen Installation und Überprüfung fließen.

Reichen WordPress-Updates, Wordfence oder eine WAF?

Ein WordPress-Update aktualisiert WordPress, kein separat betriebenes PHP-Paket. Ein Plugin kann die Fehler in der PHP-Engine ebenfalls nicht reparieren. Besonders deutlich wird das bei dem vom PHP-Projekt beschriebenen mod_php-Angriffspfad vor dem Start des Anwendungscodes: Eine erst danach laufende Plugin-Prüfung kann diesen Ablauf nicht zuverlässig abfangen.

Eine vorgeschaltete Web Application Firewall kann bekannte Anfragemuster filtern. Daraus folgt aber kein vollständiger Schutz gegen alle Ausprägungen beider Lücken. Eine PHP-seitige Reparatur muss deshalb unabhängig von WAF, Sicherheitsplugin und Anmelderatenbegrenzung nachgewiesen werden.

Umgekehrt beweist eine gefährdete PHP-Version noch keinen erfolgreichen Einbruch. Trenne im Bericht sauber zwischen „anfällig“, „Patch installiert“ und „Kompromittierung festgestellt“. Sonst wird aus der Bestandsaufnahme schnell ein Ratespiel mit vielen roten Warnsymbolen.

Was tun bei Verdacht auf einen bereits erfolgten Angriff?

Eine erfolgreiche Aktualisierung entfernt keine zuvor angelegte Hintertür. Wenn du unerwartete Dateien, Konten, Prozesse oder ausgehende Verbindungen findest, behandle das als gesonderten Sicherheitsvorfall. Das ist ein Prüfhinweis, kein spezieller Nachweis für PHP2Shell.

  • Begrenze weiteren Zugriff und verhindere eine Ausbreitung entsprechend eurem Vorfallplan.
  • Sichere relevante Protokolle und Beweisdaten, bevor du Dateien löschst oder das System neu aufsetzt.
  • Untersuche den Umfang; plane bei bestätigter Kompromittierung die Wiederherstellung aus einem vertrauenswürdigen Zustand.
  • Wechsle betroffene Zugangsdaten, Schlüssel und Anwendungstokens koordiniert über einen sauberen Administrationsweg.

Diese allgemeinen Schritte orientieren sich an den Incident-Response-Playbooks der CISA. Sie sind von der konkreten PHP-Fehlerbehebung zu unterscheiden. Ein unauffälliger Malware-Scan allein belegt keine vollständige Bereinigung.

Wann ist die akute PHP-Maßnahme abgeschlossen?

Für jede betroffene Laufzeit sollte nachvollziehbar dokumentiert sein: wo sie eingesetzt wird, aus welcher Paketquelle sie stammt, welcher korrigierte Stand installiert wurde und wie der laufende Dienst überprüft wurde. Dazu gehören bei Plesk sowohl Website-PHP als auch die interne Engine.

Notiere Aktualisierungszeitpunkt, notwendige Neustarts und den Anwendungstest. Offene Altversionen oder nicht überprüfte Knoten bleiben ausdrücklich offen. So lässt sich später unterscheiden, ob tatsächlich gepatcht wurde oder nur ein Update angeklickt war.

Quellen

Technischer und redaktioneller Abgleich am 23. Oktober 2026. Die Anleitungen sind aus Hersteller- und CERT-Unterlagen zusammengestellt; eigene Tests auf deinem Server oder bei Kunden werden damit nicht behauptet.