PHP2Shell: der Unterschied zwischen „gepatcht“ und „abgesichert“

Diese Woche wurden zwei kritische Lücken in PHP vorzeitig öffentlich: PHP2Shell, CVE-2026-109618 und CVE-2026-109619, CVSS 9.2. Beide erlauben Remote Code Execution ohne Anmeldung. Der Leak kam am 20. Oktober, die Patches am 21. Oktober – und laut Amazon Threat Intelligence gab es erste Angriffsversuche auf Honeypots schon am 17. Oktober, also vier Tage vor der Veröffentlichung.

Ein Webserver, der direkt am Internet hängt, war in diesen Tagen ungeschützt, bis das Update eingespielt war.

Stand: 22. Oktober 2026. Empfehlungen und verfügbare Updates können sich seither geändert haben – maßgeblich sind die verlinkten Quellen.

Was passiert ist

Lücken: CVE-2026-109618 (Speicherbeschädigung bei Speichermangel) und CVE-2026-109619 (veralteter globaler Zustand beim Session-Upload-Progress), beide Remote Code Execution ohne Login.
Betroffen: PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed – also praktisch jede typische PHP-Installation.
Behoben in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Betroffen sind alle Versionen ab PHP 5.4; für PHP 5.4 bis 8.1 (End of Life) gibt es keinen offiziellen Patch.
AWS hat am 21. Oktober Gegenmaßnahmen für AWS WAF veröffentlicht: die aktualisierte PHP Managed Rule Group, die Regel SizeRestrictions_BODY (Anfragen über 8 KB) und eine eigene Regel gegen das Angriffsmuster. AWS betont selbst: Das mildert, es ersetzt das Update nicht.

Die eigentliche Frage: Was passiert, wenn der Exploit durchkommt?

Wir machen kein PHP. CGS IT Solutions ist Software Engineering in Java, mit Quarkus und Spring. Aber die Frage stellt sich für jede Sprache und jedes Framework gleich: Irgendwann gibt es die nächste Lücke, und irgendwann ist ein Angreifer schneller als der Patch.

Ein Patch behebt das Problem in der betroffenen Software. Wie viel Schaden ein erfolgreicher Angriff anrichten kann, hängt von der Architektur ab: welche Rechte der kompromittierte Prozess hat, was er im Netz erreicht und wohin er Daten schicken kann. Mehrere solche Grenzen hintereinander nennt man Defense in Depth.

Zwei Architekturen im Vergleich

Links ein Server, der alles darf: öffentlich erreichbar, Anwendung und Datenbank auf einem Host, freier Weg nach draußen. Rechts dieselbe Anwendung in Schichten, jede mit eigener Grenze.

Schicht für Schicht

So setzen wir das in unserer CGS Standard Application Foundation um, der AWS-CDK-Basis für die Anwendungen, die wir ausliefern. Das Prinzip gilt aber für jede AWS-Umgebung.

1. Ein Eingang, mit Filter davor

Von außen ist nur Amazon CloudFront erreichbar, davor AWS WAF mit den Managed Rules von AWS: Core Rule Set inklusive der 8-KB-Regel für Anfragen (SizeRestrictions_BODY), Known Bad Inputs, SQL-Injection, eine IP-Reputationsliste und ein Rate Limit pro IP. In Produktion blockt die WAF, in Entwicklung zählt sie zunächst nur. Die Regeln pflegt AWS; Aktualisierungen kommen, ohne dass jemand nachts eine Regel schreiben muss.

Was das nicht leistet: Die WAF prüft eingehende Anfragen, keine Antworten. Und die PHP-spezifische Rule Group ist in unserer Basis nicht enthalten, weil wir Java-Workloads betreiben – für PHP-Anwendungen gehört sie dazu.

2. Kein Server direkt erreichbar

Der Load Balancer ist intern und nimmt nur Verkehr von CloudFront an. Die Anwendung läuft in einem privaten Subnetz und bekommt keine öffentliche IP – eine Prüfung bei jedem Build verhindert, dass das versehentlich doch passiert. Ein Angreifer kann den Server nicht direkt ansprechen, er muss durch den einen, gefilterten Eingang.

3. Ausgehenden Verkehr kontrollieren

Nach einem erfolgreichen Exploit will ein Angreifer meist zuerst nachladen: Schadsoftware, Werkzeuge, eine Reverse Shell. Dafür braucht er einen Weg nach draußen. Ausgehender Verkehr läuft bei uns nur über ein NAT-Gateway – das selbst filtert nichts. Die Kontrolle kommt von drei anderen Stellen:

Route 53 Resolver DNS Firewall mit einer Allowlist der Domains, die die Anwendung wirklich braucht. Im Standard erkennt und alarmiert sie Abfragen auf andere Domains; im Block-Modus werden sie gar nicht erst aufgelöst.
Netzwerk-ACL: DNS-Anfragen an fremde Server (Port 53) sind gesperrt, die DNS Firewall lässt sich also nicht umgehen.
Security Groups: Regeln, die ausgehend alles erlauben, meldet eine Prüfung bei jedem Build.

Wichtig für die Einordnung: Die DNS Firewall kontrolliert nur die Namensauflösung. Baut Schadcode eine Verbindung direkt zu einer IP-Adresse auf, greift sie nicht. Das begrenzen erst restriktive ausgehende Regeln in den Security Groups, die im jeweiligen Projekt festgelegt werden, oder bei höheren Anforderungen eine AWS Network Firewall. Die DNS Firewall erschwert also das Nachladen über Domainnamen und macht es sichtbar; ein vollständiger Ausgangsfilter ist sie nicht.

4. Die Datenbank ist isoliert

Die Datenbank liegt in einem eigenen Subnetz ohne Route ins Internet. Erreichbar ist sie nur von der Anwendung, abgesichert über Security Group und Netzwerk-ACL. Wartung läuft über AWS Systems Manager Session Manager – ohne offenen SSH-Port.

5. Standard statt Einzelfall

Diese Grenzen sind in jeder Umgebung von Anfang an eingebaut: als Infrastructure as Code, mit Prüfungen bei jedem Build und ausgerichtet an CIS AWS Foundations Benchmark und AWS Foundational Security Best Practices.

Was PHP-Betreiber jetzt tun sollten

Patchen: auf PHP 8.2.35, 8.3.36, 8.4.27 oder 8.5.12. Das ist der einzige echte Fix.
PHP 8.1 und älter ablösen – oder bis dahin konsequent isolieren. Für diese Versionen kommt kein offizieller Patch.
Falls das Update nicht sofort möglich ist: session.upload_progress.enabled=0 setzen und alle Worker neu starten. Das mindert laut PHP-Projekt CVE-2026-109619 teilweise, ersetzt das Update aber nicht.
AWS WAF nutzen, falls vorhanden: PHP Managed Rule Group auf die aktuelle Version, SizeRestrictions_BODY aus dem Core Rule Set und die von AWS beschriebene eigene Regel. Als Überbrückung, nicht als Ersatz für das Update.
Vom Schlimmsten ausgehen: Wie weit käme ein Angreifer, der Code auf Ihrem Server ausführt? Ausgehenden Verkehr beschränken, Rechte minimieren, Zugangsdaten aus dem Server entfernen.

Fazit

Ein Patch behebt das Problem der spezifischen Software. Eine gut strukturierte AWS- und Anwendungsarchitektur begrenzt den Schaden eines Angriffs auf eine möglichst geringe Auswirkung. Beides gehört zusammen: Updates zeitnah einspielen und die Umgebung so bauen, dass eine einzelne Lücke nicht die ganze Anwendung öffnet.

Wie widerstandsfähig ist Ihre AWS-Architektur? Wir analysieren Netzwerkgrenzen, Berechtigungen und die möglichen Auswirkungen einer kompromittierten Anwendung.

Architektur besprechen