PHP2Shell: CVE-2026-109618 & CVE-2026-109619 – Schutz und Updates

Das Wichtigste in 30 Sekunden

Direkt zu den wichtigsten Themen

Was ist PHP2Shell?

PHP2Shell bezeichnet zwei kritische Schwachstellen im PHP-Interpreter, durch die Angreifer unter bestimmten Bedingungen ohne Authentifizierung Remote Code Execution (RCE) erreichen können.

Betroffen sind CVE-2026-109618 und CVE-2026-109619. Beide Schwachstellen werden mit einem CVSS-v4.0-Wert von 9.2 bewertet.

Das bedeutet: Ein Angreifer kann unter passenden Bedingungen Code mit den Rechten des Webserver-Prozesses ausführen, ohne sich vorher an der Webanwendung anmelden zu müssen.

Quelle: PHP – Security Advisory vom 21. Oktober 2026

CVE-2026-109618: RCE durch Out-of-Memory-Korruption

Bei Speichermangel kann PHP unterbrochen werden, während interne Request-Daten nur teilweise initialisiert sind. Die anschließende Bereinigung kann diese ungültigen Daten wie gültige Daten behandeln.

Mehrere Out-of-Memory-Szenarien können diesen Zustand auslösen und dadurch Remote Code Execution ermöglichen.

Technische Details: GitHub Security Advisory GHSA-w8hw-w9fx-j79w

CVE-2026-109619: RCE durch veralteten globalen Zustand

Bei CVE-2026-109619 kann interner Request-Zustand bestehen bleiben, obwohl der zugehörige Speicher bereits freigegeben wurde. Ein späterer Request im selben Worker kann diesen veralteten Zustand nutzen, bevor die normale Initialisierung ihn zurücksetzt.

Für eine erfolgreiche Ausnutzung müssen dabei ein erzeugender und ein später konsumierender Request auf denselben Worker treffen.

Technische Details: GitHub Security Advisory GHSA-6wmf-4rv5-p3rp

Warum ein aktuelles CMS allein nicht schützt

Für Administratoren ist vor allem eines wichtig: Der Fehler liegt im PHP-Interpreter und nicht in der eigentlichen Webanwendung.

Ein vollständig aktualisiertes CMS, Shopsystem oder Intranet kann daher trotzdem auf einem verwundbaren PHP-Interpreter laufen.

Relevant sind PHP-Installationen, die Web-Requests verarbeiten, darunter:

• PHP-FPM
• Apache mit mod_php
• php-cgi
• FrankenPHP
• LiteSpeed

Besonders kritisch ist Apache mit mod_php. Laut PHP wurde für dieses Szenario ein Exploit demonstriert, der den verwundbaren Zustand bereits auslösen kann, bevor Anwendungscode ausgeführt wird.

Ein Login innerhalb der eigentlichen Webanwendung ist deshalb kein ausreichender Schutz.

Welche PHP-Versionen sind betroffen – und welche beheben PHP2Shell?

Die Sicherheitskorrekturen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 enthalten.

Für PHP 7.4, 8.0 und 8.1 hat das PHP-Projekt Quellcode-Backports bereitgestellt. Reguläre Binary-Releases für diese bereits abgekündigten Zweige werden jedoch nicht mehr veröffentlicht.

Wird PHP2Shell bereits ausgenutzt?

Ja, es wurden bereits Exploit-Versuche beobachtet.

Sophos dokumentiert in seinem am 22. Oktober aktualisierten Advisory, dass Exploit-Versuche mindestens seit dem 17. Oktober 2026 beobachtet wurden. Damit gab es entsprechende Aktivitäten bereits vor der öffentlichen Offenlegung und vor Veröffentlichung der korrigierten PHP-Versionen.

Quelle: Sophos Security Advisory – PHP2Shell

Was sagt Sophos zu PHP2Shell?

Sophos hat das Security Advisory sophos-sa-20261021-php2shell am 21. Oktober veröffentlicht und am 22. Oktober weiter aktualisiert.

Der aktuelle Stand ist eindeutig: Keine Sophos-Produkte sind von CVE-2026-109618 oder CVE-2026-109619 betroffen.

Für Sophos-Kunden ist der Handlungsbedarf daher in erster Linie bei eigenen PHP-Systemen sowie bei Drittanbieter-Produkten zu prüfen, die PHP enthalten.

Sophos Firewall und Endpoint: neue IPS-Signaturen

Seit dem 22. Oktober 2026 stehen laut Sophos IPS-Signaturen für Sophos Firewall und Sophos Endpoint zur Verfügung, die Versuche zur Ausnutzung der beiden Schwachstellen erkennen können.

Was ist mit der Sophos Firewall WAF?

Sophos stellt im aktuellen Advisory ausdrücklich klar, dass die Sophos Firewall Web Application Firewall derzeit keine spezifische Schutzfunktion für diese beiden Schwachstellen enthält.

Allgemeine WAF-Maßnahmen wie Request-Limits, vorgeschaltete Authentifizierung oder das Blockieren nicht benötigter Request-Typen können die Angriffsfläche trotzdem verkleinern. Sie dürfen jedoch nicht als CVE-spezifischer Schutz verstanden werden.

Hinweis zum MyUTM-Portal

Das ältere von Sophos gehostete MyUTM-Portal, das als Lizenzierungsdienst für die End-of-Life-SG-UTM-Plattform dient, verwendete laut Sophos eine betroffene PHP-Version.

Sophos nahm den Dienst am 21. Oktober offline und aktualisiert ihn. Laut Advisory wurden bei der laufenden Log-Prüfung bislang keine Hinweise auf eine Ausnutzung gefunden.

Das ändert nichts an der Aussage, dass keine Sophos-Produkte selbst von den Schwachstellen betroffen sind.

Sophos-Quelle: Sophos Security Advisory zu PHP2Shell

Warum die Firewall PHP2Shell nicht vollständig verhindern kann

Eine Firewall kann das Risiko durch PHP2Shell reduzieren, die eigentliche Schwachstelle aber nicht beseitigen.

Der Fehler befindet sich direkt im PHP-Interpreter auf dem Webserver. Das PHP-Projekt weist ausdrücklich darauf hin, dass es keine vollständige Mitigation gibt und das Update die einzige sichere Lösung ist.

Vereinfacht lässt sich die Firewall mit einem Türsteher vergleichen: Sie kann problematische Requests abweisen und den Zugang einschränken. Ist jedoch das Schloss selbst defekt, muss es trotzdem repariert werden.

Genau diese Reparatur übernimmt das PHP-Update.

Welche Firewall- und WAF-Maßnahmen helfen gegen PHP2Shell?

Wenn ein PHP-Update nicht sofort möglich ist, können mehrere Maßnahmen die Angriffsfläche verkleinern. Auf einer Sophos Firewall kommen dafür insbesondere IPS, WAF-Schutzmaßnahmen, Zugriffsbeschränkungen und vorgeschaltete Authentifizierung infrage.

IPS-Schutz aktuell halten

Für Sophos Firewall und Sophos Endpoint stehen seit dem 22. Oktober 2026 IPS-Signaturen zur Erkennung von Exploit-Versuchen gegen CVE-2026-109618 und CVE-2026-109619 bereit.

Stellen Sie sicher, dass die entsprechenden Schutzfunktionen aktiv sind und aktuelle Signaturen bezogen werden.

Auch hier gilt: IPS erkennt beziehungsweise blockiert bekannte Angriffsmuster, repariert aber nicht den verwundbaren PHP-Interpreter.

Nicht benötigte Uploads und Multipart-Requests blockieren

Sophos empfiehlt für Anwendungen, die keine Datei-Uploads benötigen, Datei-Uploads in PHP zu deaktivieren und multipart/form-data-Requests bereits am Webserver oder an der WAF abzuweisen, bevor diese PHP erreichen.

Diese Maßnahme ist nur für Anwendungen geeignet, die tatsächlich keine entsprechenden Upload-Funktionen benötigen.

Request-Größe und Request-Komplexität begrenzen

Limits auf Webserver-, Reverse-Proxy- oder WAF-Ebene können bekannte Out-of-Memory-Angriffspfade erschweren.

Das PHP-Sicherheitsadvisory nennt bei Systemen, die nicht sofort aktualisiert werden können, unter anderem ein reduziertes post_max_size.

Für Anwendungen ohne Datei-Uploads werden 8M, bei notwendigen Uploads 32M genannt.

upload_max_filesize sollte darunter liegen.

Zusätzlich können Grenzen für Eingabefelder, Multipart-Teile, Header, Uploads und Verschachtelungstiefe sinnvoll sein.

Sophos-Dokumentation: Sophos Firewall – WAF Protection Policies

Form Hardening als zusätzliche WAF-Schutzschicht

Form Hardening kann manipulierte Formularübermittlungen erkennen und als zusätzliche WAF-Schutzschicht zurückweisen.

Die Sophos Firewall speichert hierzu die ursprüngliche Struktur eines Webformulars und signiert diese. Wird die Struktur bei der Übermittlung manipuliert, kann die Anfrage verworfen werden.

Weitere Informationen: Web Application Firewall auf der Sophos Firewall konfigurieren

Zugriff auf den Webserver einschränken

Je weniger Systeme und Benutzer einen verwundbaren Webserver erreichen können, desto kleiner ist seine Angriffsfläche.

Für interne Anwendungen kommen beispielsweise folgende Maßnahmen infrage:

• Authentifizierung vor dem eigentlichen PHP-Webserver
• Zugriff nur aus definierten Quellnetzen
• Anwendung vorübergehend aus dem Internet entfernen
• Zugriff ausschließlich über VPN oder ZTNA ermöglichen

Besonders für Administrationsoberflächen, Intranet-Anwendungen und interne Control Panels kann Sophos ZTNA die direkte Internetexposition reduzieren.

Welche Schutzmaßnahme ist wann sinnvoll?

Ergänzende PHP-Einstellungen als Übergangslösung

Zusätzlich zu Firewall- und WAF-Maßnahmen nennt das PHP-Projekt mehrere Konfigurationseinstellungen für Systeme, die nicht sofort aktualisiert werden können.

Diese Einstellungen sind Übergangsmaßnahmen und kein Ersatz für das Update.

Session Upload Progress deaktivieren

Mit session.upload_progress.enabled=0 lassen sich bestätigte Session-Angriffspfade für CVE-2026-109619 blockieren.

Der Wert muss so gesetzt werden, dass er bereits vor dem eigentlichen Request-Parsing greift. Anschließend müssen die betroffenen PHP-Worker neu gestartet werden.

Fatal Error Backtraces unter PHP 8.5 deaktivieren

Unter PHP 8.5 kann fatal_error_backtraces=0 den bestätigten Fatal-Backtrace-Angriffspfad schließen.

Auch diese Einstellung schützt nur vor diesem konkreten Pfad.

PHP-Speicherlimit anpassen

Eine weitere Übergangsmaßnahme ist memory_limit=-1.

Dadurch entfällt das kontrollierbare PHP-Speicherlimit als einer der möglichen Auslöser für CVE-2026-109618. Ein Allokationsfehler auf einer darunterliegenden Ebene kann jedoch weiterhin auftreten.

Ein unbegrenztes PHP-Speicherlimit kann außerdem die Verfügbarkeit eines Servers beeinträchtigen. Container- oder cgroup-Grenzen können deshalb als zusätzliche Verfügbarkeitsgrenze sinnvoll sein.

Nicht verwendet werden sollten hierfür RLIMIT_AS oder RLIMIT_DATA, da diese den verwundbaren Allokationsfehler selbst auslösen können.

Fehlerauslösende Konfigurationen prüfen

Für CVE-2026-109619 sollten außerdem ungültige oder veraltete Konfigurationseinstellungen sowie von außen auslösbare Fatal Errors und Timeouts geprüft werden.

Das reine Unterdrücken der Fehlermeldung schützt nicht vor der Schwachstelle.

Wie finde ich verwundbare PHP-Installationen?

Erfassen Sie PHP aus der tatsächlich laufenden Umgebung und nicht nur aus einer Asset-Liste.

Berücksichtigen Sie insbesondere:

• Webserver
• PHP-FPM-Instanzen
• Container-Images
• Control Panels
• Test- und Entwicklungssysteme
• Appliances und Drittanbieter-Produkte mit eingebettetem PHP
• Hosting-Umgebungen

Sophos empfiehlt außerdem, den PHP-Patchstand aus der tatsächlichen Laufzeit zu ermitteln. Die CLI-Version kann von der PHP-Version abweichen, die beispielsweise über PHP-FPM oder mod_php verwendet wird.

PHP2Shell mit Sophos XDR oder MDR suchen

Kunden mit Sophos XDR oder Sophos MDR können zusätzlich die PHP2Shell-Threat-Hunting-Queries aus der Sophos-Community verwenden.

Quelle: Sophos Community – XDR Threat Hunting Queries

Für PHP2Shell stehen dort unter anderem Varianten für Red Hat und Debian bereit.

Fusion AI Security Assistant

Zusätzlich kann der Fusion AI Security Assistant bei der Untersuchung unterstützen.

Ein möglicher Prompt lautet:

PHP-Version direkt prüfen

Beachten Sie: Diese Befehle allein beweisen noch nicht, welche PHP-Version tatsächlich eine Webanfrage verarbeitet.

PHP2Shell: Nach dem Update auf Kompromittierung prüfen

Ein Sicherheitsupdate schließt die Schwachstelle, entfernt aber keine Webshell und macht einen bereits erfolgten Angriff nicht rückgängig.

Da Exploit-Versuche bereits vor Veröffentlichung der Updates beobachtet wurden, empfiehlt Sophos für exponierte Systeme eine nachträgliche Prüfung.

Sophos empfiehlt vorsorglich, Aktivitäten auf öffentlich erreichbaren betroffenen Systemen ab dem 1. August 2026 zu überprüfen.

Diese Bereiche sollten Sie kontrollieren

Wenn Hinweise auf eine Kompromittierung bestehen, sollten nicht nur verdächtige Dateien entfernt werden. Zugangsdaten, API-Schlüssel und Tokens, auf die der Webserver-Prozess Zugriff hatte, müssen in die Untersuchung einbezogen und gegebenenfalls erneuert werden.

Quelle: Sophos – Checking for signs of compromise

Typische Fehler beim Schutz vor PHP2Shell

Nur patchen und die Zeit davor ignorieren

Da Exploit-Versuche vor Verfügbarkeit der Sicherheitsupdates beobachtet wurden, reicht es bei exponierten Systemen nicht immer aus, lediglich die aktuelle PHP-Version einzuspielen.

Firewall-Regeln als Ersatz für das Update betrachten

IPS, Request-Limits und WAF-Schutzmechanismen können die Angriffsfläche verkleinern, beseitigen den Fehler im PHP-Interpreter jedoch nicht.

Nur die PHP-Version des Hosts prüfen

PHP kann zusätzlich in Containern, Appliances, Control Panels oder separaten Webserver-Instanzen eingesetzt werden.

Jede ältere Versionsnummer automatisch als verwundbar einstufen

Linux-Distributionen können Sicherheitsfixes zurückportieren. Prüfen Sie deshalb zusätzlich das Paket-Changelog oder die Security Advisory des jeweiligen Distributors.

Request-Limits ohne Anwendungstest aktivieren

Zu niedrige Limits können legitime Datei-Uploads, Formulare oder API-Aufrufe beeinträchtigen.

Den Login der Webanwendung als Schutz ansehen

Ein Login innerhalb der Anwendung schützt insbesondere bei mod_php nicht zwangsläufig vor PHP2Shell, da ein Angriff bereits vor Ausführung des Anwendungscodes greifen kann.

PHP2Shell beheben: PHP jetzt aktualisieren

Um PHP2Shell vollständig zu beheben, müssen betroffene Systeme auf eine korrigierte PHP-Version oder ein entsprechend gepatchtes Distributionspaket aktualisiert werden.

1. Alle PHP-Instanzen erfassen: Webserver, Container, Control Panels, Appliances und Testsysteme berücksichtigen.
2. Internetexponierte Systeme priorisieren: insbesondere Apache-mod_php-Installationen zuerst behandeln.
3. Gepatchte Version installieren: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 beziehungsweise das korrigierte Paket des Distributors verwenden.
4. Container-Images neu erstellen: Basis-Images aktualisieren, neu bauen und erneut ausrollen.
5. PHP-Worker und Webserver neu starten: damit neue Pakete und geänderte Einstellungen tatsächlich verwendet werden.
6. Effektiven Patchstand kontrollieren: nicht nur die CLI-Version, sondern die tatsächlich für Webanfragen verwendete PHP-Laufzeit prüfen.
7. Exponierte Systeme untersuchen: Logs, Prozesse, Dateien, Netzwerkverbindungen und administrative Logins kontrollieren.

Für PHP 8.1 und ältere Versionen ist ein Wechsel auf einen unterstützten PHP-Zweig beziehungsweise ein Backport durch Distributor oder LTS-Anbieter erforderlich.

PHP 8.2 erreicht am 31. Dezember 2026 sein Support-Ende. Wer noch PHP 8.2 einsetzt, sollte deshalb die Migration auf einen länger unterstützten Zweig direkt mit einplanen.

Unsere Empfehlung

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell?

PHP2Shell ist die Bezeichnung für die beiden kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Beide können unter bestimmten Bedingungen Remote Code Execution ohne vorherige Anmeldung ermöglichen.

Wird PHP2Shell bereits aktiv ausgenutzt?

Es wurden bereits Exploit-Versuche beobachtet. Sophos nennt entsprechende Aktivitäten seit mindestens dem 17. Oktober 2026.

Welche PHP-Versionen enthalten den Fix?

Die Sicherheitskorrekturen sind in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 enthalten.

Sind Sophos-Produkte von PHP2Shell betroffen?

Nein. Laut dem am 22. Oktober 2026 aktualisierten Sophos Advisory sind keine Sophos-Produkte von CVE-2026-109618 oder CVE-2026-109619 betroffen.

Schützt Sophos Firewall vor PHP2Shell?

Sophos hat am 22. Oktober 2026 IPS-Signaturen für Sophos Firewall veröffentlicht, die Exploit-Versuche erkennen können.

Die Sophos Firewall WAF enthält laut aktuellem Advisory jedoch keine spezifische Schutzfunktion für diese Schwachstellen. Allgemeine WAF-Maßnahmen können das Risiko reduzieren, ersetzen aber weder IPS noch PHP-Update.

Reicht das PHP-Update aus, wenn der Server vorher öffentlich erreichbar war?

Das Update schließt die Schwachstellen, beseitigt aber keine bereits erfolgte Kompromittierung. Exponierte Systeme sollten deshalb zusätzlich auf auffällige Logs, Prozesse, Dateien, Netzwerkverbindungen und administrative Anmeldungen geprüft werden.

Sind nur Server mit mod_php betroffen?

Nein. PHP nennt unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt derzeit bei mod_php.

Kann eine Firewall PHP2Shell vollständig verhindern?

Nein. IPS, WAF, Zugriffsbeschränkungen und ZTNA können das Risiko reduzieren. Die Schwachstellen selbst werden ausschließlich durch ein korrigiertes PHP-Paket beseitigt.

Was soll ich tun, wenn ich PHP nicht sofort aktualisieren kann?

Reduzieren Sie die Internetexposition, verwenden Sie gegebenenfalls ZTNA oder vorgeschaltete Authentifizierung, deaktivieren Sie nicht benötigte Upload-Funktionen, setzen Sie die dokumentierten PHP-Übergangsmaßnahmen um und installieren Sie das eigentliche Sicherheitsupdate so schnell wie möglich.

Fazit: PHP2Shell patchen – und exponierte Systeme anschließend prüfen

PHP2Shell gehört zu den Schwachstellen, bei denen ein schnelles Update höchste Priorität hat. CVE-2026-109618 und CVE-2026-109619 liegen direkt im PHP-Interpreter und können eine Remote Code Execution ohne vorherige Anmeldung ermöglichen.

Mit PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 stehen korrigierte Versionen bereit.

Für Sophos-Kunden gibt es gleichzeitig eine wichtige Entwarnung: Nach aktuellem Sophos Advisory sind keine Sophos-Produkte betroffen.

Sophos Firewall und Endpoint besitzen seit dem 22. Oktober zusätzliche IPS-Signaturen zur Erkennung von Exploit-Versuchen. WAF, IPS und Zugriffsbeschränkungen bleiben jedoch ergänzende Schutzebenen – sie ersetzen das PHP-Update nicht.

Da bereits vor Veröffentlichung des Patches Exploit-Versuche beobachtet wurden, sollte bei öffentlich erreichbaren PHP-Systemen nach dem Patch zusätzlich geprüft werden, ob es Anzeichen einer bereits erfolgten Kompromittierung gibt.

Fragen zur Absicherung Ihrer Webserver?

Sie möchten prüfen, welche Schutzmaßnahmen Ihre vorhandene Sophos Firewall bietet oder wie Sie PHP2Shell-Aktivitäten mit Sophos XDR beziehungsweise MDR untersuchen können?

Wir prüfen gemeinsam mit Ihnen den technischen Ausgangsstand und zeigen, welche Maßnahmen für Ihre Umgebung sinnvoll sind.

Kontakt