PHP2Shell: Webserver per Firewall absichern

Das Wichtigste in 30 Sekunden

• PHP2Shell umfasst zwei kritische PHP-Schwachstellen: CVE-2026-109618 und CVE-2026-109619.
• Angreifer können unter bestimmten Bedingungen ohne Anmeldung Code auf betroffenen Webservern ausführen.
• Das PHP-Projekt hat am 21. Oktober 2026 korrigierte Versionen veröffentlicht.
• Eine vorhandene Sophos Firewall kann mit WAF- und Zugriffsschutzmaßnahmen die Angriffsfläche reduzieren.
• Keine dieser Maßnahmen ersetzt das PHP-Update. Nur die Sicherheitskorrektur beseitigt die Schwachstellen im PHP-Interpreter.

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.

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

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

Relevant sind PHP-Installationen, die Web-Requests verarbeiten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Besonders kritisch ist mod_php. Laut offiziellem PHP-Sicherheitsadvisory wurde hierfür ein Exploit demonstriert, der den verwundbaren Zustand auslösen kann, bevor Anwendungscode ausgeführt wird. Ein Login innerhalb der Webanwendung ist deshalb kein ausreichender Schutz.

Was sagt Sophos zu PHP2Shell?

Sophos hat für CVE-2026-109618 und CVE-2026-109619 ein eigenes Security Advisory veröffentlicht. Zusätzlich beobachtet die Sophos Counter Threat Unit die Bedrohungslage rund um PHP2Shell.

Sophos empfiehlt, PHP-Installationen in der eigenen Umgebung zu inventarisieren, betroffene Systeme zu aktualisieren und insbesondere öffentlich erreichbare Systeme zu prüfen.

Für Sophos-Firewall-Kunden ist außerdem wichtig: Die Sophos Firewall selbst verwendet laut Sophos kein PHP und ist daher nicht von diesen beiden PHP-Schwachstellen betroffen.

Gleichzeitig hat Sophos in der Community darauf hingewiesen, dass die dort beschriebene WAF-Konfiguration keine speziellen Erkennungsregeln für diese beiden CVEs enthält.

Die in diesem Artikel beschriebenen WAF-, Zugriffs- und Request-Maßnahmen sind deshalb als zusätzliche Risikoreduktion zu verstehen und nicht als CVE-spezifische Signatur oder Ersatz für das PHP-Sicherheitsupdate.

Sophos-Quellen: Sophos Security Advisory zu PHP2Shell | Sophos Counter Threat Unit: PHP2Shell | Sophos Community: Firewall und WAF

Welche PHP-Versionen 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 minimale Quellcode-Backports bereitgestellt. Diese sind insbesondere relevant, wenn PHP selbst gebaut wird oder kein entsprechender LTS-Anbieter eingesetzt wird.

Bei Linux-Distributionen sollten Administratoren nicht ausschließlich auf die angezeigte Upstream-Versionsnummer schauen. Distributionen können Sicherheitskorrekturen zurückportieren, ohne die ursprüngliche PHP-Version vollständig anzuheben.

Prüfen Sie deshalb zusätzlich das Paket-Changelog beziehungsweise die Security Advisory Ihrer Distribution.

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 offizielle PHP-Sicherheitsadvisory weist darauf hin, dass nur ein Update die beiden Schwachstellen vollständig behebt.

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

Genau diese Reparatur übernimmt das PHP-Update.

Firewall- und WAF-Regeln sind deshalb vor allem temporäre Maßnahmen zur Risikoreduktion, wenn ein Update nicht sofort möglich ist.

Welche Firewall-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 WAF-Schutzmaßnahmen, Zugriffsbeschränkungen und eine vorgeschaltete Authentifizierung infrage.

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

Limits auf Webserver- oder Proxy-Ebene können bekannte Out-of-Memory-Angriffspfade von CVE-2026-109618 erschweren.

Das offizielle PHP-Sicherheitsadvisory empfiehlt bei Systemen, die nicht sofort aktualisiert werden können, zunächst ein niedriges post_max_size.

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

upload_max_filesize sollte unterhalb von post_max_size liegen.

Zusätzlich sollten bereits am Webserver oder Reverse Proxy Grenzen für die dekodierte Request-Größe sowie für Eingabefelder, Multipart-Teile, Header, Uploads und die Verschachtelungstiefe gesetzt werden.

In der Webserver Protection der Sophos Firewall können entsprechende Request-Limits als zusätzliche Schutzschicht eingesetzt werden. Ein einzelner Grenzwert stellt jedoch keine vollständige Mitigation für PHP2Shell dar.

Sophos-Dokumentation: Sophos Firewall – WAF Protection Policies

Berücksichtigen Sie bei der Konfiguration legitime Anwendungsfälle wie:

• Dokumentenportale
• Datei-Uploads
• CMS-Medienbibliotheken
• Webanwendungen mit größeren Formularübertragungen

Wichtig sind auch Requests ohne verwertbaren Content-Length-Header. Entsprechende Schutzgrenzen müssen auch solche Requests erfassen.

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 zur Konfiguration: Web Application Firewall (WAF) auf der Sophos Firewall konfigurieren

Form Hardening ist jedoch keine vom PHP-Projekt bestätigte vollständige Mitigation für CVE-2026-109619. Für den bestätigten Session-Upload-Progress-Pfad nennt das PHP-Advisory stattdessen session.upload_progress.enabled=0.

Vor einer produktiven Aktivierung sollten Sie die Auswirkungen testen. Form Hardening kann insbesondere Probleme verursachen bei:

• AJAX-Aufrufen
• APIs
• dynamisch erzeugten Formularfeldern
• Anwendungen mit wechselndem Formularaufbau

Testen Sie die Regel möglichst zunächst in einer Testumgebung oder während eines Wartungsfensters und kontrollieren Sie anschließend die WAF- beziehungsweise Firewall-Logs.

Zugriff auf den Webserver einschränken

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

Da beide Schwachstellen ohne vorherige Authentifizierung über Web-Requests ausgelöst werden können, kann eine Einschränkung des Zugriffs besonders wirkungsvoll sein.

Drei Möglichkeiten bieten sich an:

1. Authentifizierung vor dem Webserver vorschalten, beispielsweise über die WAF.
2. Quell-Adressen einschränken, sodass nur bekannte Netzwerke den Server erreichen können.
3. Webserver aus dem öffentlichen Internet entfernen und den Zugriff ausschließlich über VPN oder ZTNA ermöglichen.

Die vorgeschaltete Authentifizierung muss vor der eigentlichen PHP-Anwendung greifen.

Ein Login innerhalb der Anwendung reicht insbesondere bei mod_php nicht aus, weil der bekannte Exploit bereits vor der Ausführung des Anwendungscodes greifen kann.

Für Administrationsoberflächen, interne Anwendungen, Intranet-Dienste und Control Panels wie Plesk ist ein Zugriff über VPN oder ZTNA eine besonders starke Variante, sofern der jeweilige Anwendungsfall dies zulässt.

Welche Schutzmaßnahme ist wann sinnvoll?

Nicht jede Übergangsmaßnahme passt zu jeder Anwendung. Die folgende Übersicht hilft bei der technischen Einordnung.

Firewall- und Konfigurationsmaßnahmen gewinnen Zeit. Das PHP-Update beseitigt die Schwachstellen.

Ergänzende PHP-Einstellungen als Übergangslösung

Zusätzlich zu Firewall- und WAF-Maßnahmen nennt das offizielle PHP-Sicherheitsadvisory Einstellungen, mit denen sich bestätigte Angriffspfade einschränken lassen. Auch diese Maßnahmen ersetzen das Update nicht.

Session Upload Progress deaktivieren

Mit session.upload_progress.enabled=0 lassen sich die bestätigten Session-Angriffspfade für CVE-2026-109619 blockieren. Andere Varianten werden dadurch nicht verhindert.

Der Wert sollte in der php.ini, der FPM-Pool-Konfiguration oder der Serverkonfiguration gesetzt werden, sodass er bereits vor dem Request-Parsing greift.

Anschließend müssen alle betroffenen PHP-Worker neu gestartet werden. ini_set() oder die FPM- .user.ini greifen hierfür zu spät.

Fatal Error Backtraces deaktivieren

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

Auch diese Einstellung schützt nur gegen diesen bestätigten Pfad und ersetzt das Update nicht.

POST-Größe begrenzen

Das PHP-Advisory nennt als mögliche Übergangseinstellungen:

• post_max_size = 8M ohne Datei-Uploads
• post_max_size = 32M bei notwendigen Uploads

upload_max_filesize sollte unterhalb des jeweiligen Wertes liegen.

PHP-Speicherlimit anpassen

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

Der Wert sollte möglichst über php_admin_value gesetzt werden, damit Anwendungen ihn nicht selbst überschreiben können.

Dadurch entfällt das kontrollierbare PHP-Speicherlimit als möglicher Auslöser. Ein Fehler bei einer darunterliegenden Speicherallokation kann den verwundbaren Pfad jedoch weiterhin erreichen.

Ein unbegrenztes PHP-Speicherlimit erhöht gleichzeitig das Risiko einer Speichererschöpfung.

Das PHP-Advisory empfiehlt deshalb alternativ beziehungsweise ergänzend ein Container- oder cgroup-Limit als Verfügbarkeitsgrenze.

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

Fehlerauslösende Konfigurationen und Fatal Errors prüfen

Für CVE-2026-109619 empfiehlt das PHP-Advisory außerdem, ungültige oder veraltete Einstellungen zu entfernen, die bereits vor der normalen Request-Initialisierung Diagnosen auslösen.

Auch für Angreifer erreichbare Fatal Errors und Timeouts sollten behoben werden, beispielsweise in Callback-, Upload-, Import- oder Cleanup-Prozessen.

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

Wie finde ich verwundbare PHP-Installationen?

Erfassen Sie alle PHP-Installationen auf Servern, in Containern, Control Panels und Testsystemen und vergleichen Sie deren Patchstand mit den korrigierten Versionen.

Besondere Priorität sollten Systeme erhalten, die direkt aus dem Internet erreichbar sind.

PHP2Shell mit Sophos XDR oder MDR suchen

Kunden mit Sophos XDR oder Sophos MDR können dafür die Threat-Hunting-Queries der Sophos-Community verwenden.

Quelle: Sophos Community – XDR Threat Hunting Queries

Für PHP2Shell stehen dort drei Varianten zur Verfügung:

• PHP2Shell_RedHat_Debian
• PHP2Shell_Debian
• PHP2Shell_RedHat

Die kombinierte Query für Red Hat und Debian sucht nach installierten PHP-Paketen, deren Versionsstand unter den veröffentlichten Fix-Versionen liegt, sowie nach PHP 8.1 und älteren Versionen.

Wichtig für die Bewertung: Ein Treffer ist zunächst ein Prüfauftrag und nicht automatisch der Nachweis einer verwundbaren Installation.

Linux-Distributionen können Sicherheitskorrekturen zurückportieren, ohne die Upstream-Versionsnummer entsprechend anzuheben. Prüfen Sie deshalb das Paket-Changelog oder die Security Advisory Ihrer Distribution.

Weitere Sophos-Informationen: Sophos XDR Dokumentation | Sophos MDR – Threat Hunting und Investigations

PHP2Shell mit dem Fusion AI Security Assistant untersuchen

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

Ein möglicher Prompt lautet:

PHP-Version direkt auf dem System prüfen

Ohne XDR oder MDR lässt sich die installierte PHP-Version direkt auf dem jeweiligen System kontrollieren.

Vergessen Sie dabei Container-Images nicht. Dort steckt die eingesetzte PHP-Version im jeweiligen Image und nicht zwangsläufig im Paketmanager des Hosts.

Auch Control Panels und ältere Testsysteme sollten in die Bestandsaufnahme einbezogen werden.

Typische Fehler beim Schutz vor PHP2Shell

Firewall-Regeln als Ersatz für das Update betrachten

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, Testsystemen oder separaten Webserver-Instanzen eingesetzt werden. Eine Prüfung ausschließlich mit php -v auf dem Host reicht deshalb nicht immer aus.

Jede ältere Versionsnummer automatisch als verwundbar einstufen

Linux-Distributionen können Sicherheitsfixes zurückportieren, ohne die ursprüngliche PHP-Versionsnummer vollständig anzuheben. Bewerten Sie deshalb zusätzlich das Paket-Changelog oder die Security Advisory.

Request-Limits ohne Anwendungstest aktivieren

Niedrige Limits können legitime Datei-Uploads, große Formulare oder API-Aufrufe beeinträchtigen. Prüfen Sie deshalb vor der Änderung die Anforderungen der jeweiligen Webanwendung.

Den Login der Webanwendung als Schutz ansehen

Ein Login innerhalb der Anwendung schützt nicht zwangsläufig vor PHP2Shell. Insbesondere bei mod_php kann ein Angriff greifen, bevor Anwendungscode ausgeführt wird.

PHP2Shell beheben: PHP aktualisieren

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

1. Alle PHP-Instanzen erfassen: Server, Container, Control Panels und ältere Testsysteme prüfen.
2. Gepatchte PHP-Version installieren: Pakete der Distribution oder den korrigierten Quellcode verwenden.
3. Container-Images neu erstellen: Basis-Image aktualisieren, neu bauen und erneut ausrollen.
4. PHP beziehungsweise den Webserver neu starten: PHP-FPM oder den jeweiligen Webserver neu starten.
5. Patchstand erneut kontrollieren: Prüfen, ob tatsächlich die korrigierte Version oder ein gepatchtes Distributionspaket aktiv ist.

Bei Drittanbieter-Repositories sollte zusätzlich geprüft werden, für welche Betriebssystem- und PHP-Zweige tatsächlich korrigierte Pakete bereitgestellt werden.

Für das Remi-Repository teilte der Maintainer am 21. Oktober 2026 mit, dass aktualisierte Pakete für Fedora 43 und neuer sowie RHEL 8 und neuer vorgesehen sind. Für EL7 wurden dagegen keine entsprechenden aktualisierten Builds angekündigt.

Quelle: Remi Repository – Hinweis zu den PHP-Sicherheitsupdates

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

PHP 8.2 erreicht am 31. Dezember 2026 sein Support-Ende. Wird noch PHP 8.2 eingesetzt, sollte die Migration auf einen länger unterstützten Zweig direkt mit eingeplant werden.

Unsere Empfehlung

Priorisieren Sie zuerst PHP-Systeme, die direkt aus dem Internet erreichbar sind, und installieren Sie die verfügbaren Sicherheitsupdates so schnell wie möglich.

Wenn ein sofortiges Update wegen technischer Abhängigkeiten nicht möglich ist, reduzieren Sie die Angriffsfläche bis zur Aktualisierung gezielt.

• Request-Größe und Request-Komplexität begrenzen
• Form Hardening als zusätzliche WAF-Schutzschicht prüfen
• Zugriff auf bekannte Quellnetze beschränken
• Authentifizierung vor den Webserver schalten
• interne Anwendungen nur über VPN oder ZTNA bereitstellen
• die vom PHP-Projekt dokumentierten Übergangsmaßnahmen einsetzen

Prüfen Sie parallel mit Sophos XDR, Sophos MDR oder direkt auf den jeweiligen Systemen, ob weitere PHP-Installationen betroffen sind.

Firewall- und WAF-Maßnahmen sollten immer als temporäre Risikoreduktion betrachtet werden.

Häufige Fragen zu PHP2Shell

Kann meine Firewall PHP2Shell vollständig verhindern?

Nein. Eine Firewall kann das Risiko reduzieren, die eigentlichen Schwachstellen CVE-2026-109618 und CVE-2026-109619 jedoch nicht beheben.

Request-Limits, Zugriffsbeschränkungen oder WAF-Schutzmechanismen können Angriffspfade erschweren. Die vollständige Lösung ist das PHP-Update.

Welche PHP-Versionen enthalten den Fix für PHP2Shell?

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

Bei Linux-Distributionspaketen kann der Fix bereits als Backport enthalten sein, obwohl die angezeigte Upstream-Versionsnummer niedriger ist. Prüfen Sie deshalb das Paket-Changelog beziehungsweise die Security Advisory.

Sind nur Server mit mod_php von PHP2Shell betroffen?

Nein. Relevant sind unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Besonders kritisch ist mod_php, weil dort ein Angriff demonstriert wurde, der vor der Ausführung von Anwendungscode greifen kann.

Warum bieten Request-Limits nur Teilschutz?

PHP2Shell lässt sich nicht auf einen einzelnen festen Request-Grenzwert reduzieren. Bei CVE-2026-109618 spielen Out-of-Memory-Situationen und verschiedene Formen der Eingabeverarbeitung eine Rolle.

Limits für Request-Größe, Multipart-Teile, Header und Eingabefelder können bestimmte Angriffspfade erschweren, beseitigen die Schwachstelle aber nicht.

Wie finde ich verwundbare PHP-Versionen in meiner Umgebung?

Erfassen Sie alle PHP-Installationen auf Servern, in Containern, Control Panels und Testsystemen und vergleichen Sie deren Patchstand mit den korrigierten Versionen.

Mit Sophos XDR oder Sophos MDR können zusätzlich die PHP2Shell-Threat-Hunting-Queries der Sophos-Community eingesetzt werden.

Schützt eine Sophos Firewall WAF vor PHP2Shell?

Die WAF einer Sophos Firewall kann die Angriffsfläche reduzieren, behebt PHP2Shell aber nicht.

Request-Limits, vorgeschaltete Authentifizierung, Quell-IP-Beschränkungen und weitere WAF-Schutzmechanismen können die Erreichbarkeit oder bestimmte problematische Requests einschränken.

Form Hardening schützt speziell gegen manipulierte Webformulare. Es ist jedoch keine vom PHP-Projekt bestätigte vollständige Mitigation für CVE-2026-109619.

Sophos weist zudem darauf hin, dass die dort beschriebene WAF-Konfiguration keine speziellen Erkennungsregeln für diese beiden CVEs enthält.

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

Reduzieren Sie zunächst die Angriffsfläche. Prüfen Sie Request-Limits, vorgeschaltete Authentifizierung, Quell-IP-Beschränkungen sowie VPN oder ZTNA für Anwendungen, die nicht öffentlich erreichbar sein müssen.

Setzen Sie außerdem die vom PHP-Projekt dokumentierten Übergangsmaßnahmen um und bereiten Sie parallel das eigentliche Sicherheitsupdate vor.

Fazit: Firewall schützt übergangsweise – das PHP-Update bleibt entscheidend

PHP2Shell zeigt, warum bei kritischen Schwachstellen mehrere Schutzebenen zusammenspielen müssen.

Eine Sophos Firewall kann mit WAF-Regeln, Request-Limits, Authentifizierung und Zugriffsbeschränkungen die Angriffsfläche verkleinern und damit das Risiko bis zum Update reduzieren.

Sie beseitigt jedoch nicht den Fehler im PHP-Interpreter.

Priorisieren Sie deshalb öffentlich erreichbare Systeme und aktualisieren Sie diese auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 beziehungsweise auf ein entsprechend korrigiertes Paket Ihrer Distribution.

Berücksichtigen Sie dabei auch Container, Control Panels und ältere Systeme, die bei einer klassischen Serverinventur leicht übersehen werden.

Fragen zur Absicherung Ihrer Webserver?

Sie möchten prüfen, welche Schutzmaßnahmen Ihre vorhandene Sophos Firewall bietet oder wie sich ein öffentlich erreichbarer Webserver bis zum PHP-Update sinnvoll absichern lässt?

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

Kontakt