PHP2Shell: Jetzt patchen und das Zeitfenster für Angreifer schließen

Was passiert ist

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619, bekannt unter dem Namen PHP2Shell. Beide ermöglichen Remote Code Execution ohne Authentifizierung. Eine einzige präparierte Anfrage genügt, und der Fehler wird ausgelöst, bevor überhaupt Anwendungscode läuft. CMS, Framework oder Login-Seite schützen hier nicht.

Erste Angriffsversuche wurden bereits Stunden vor dem Patch gemeldet. Technische Analysen und ein Exploit-Tool sind öffentlich verfügbar.

Warum diese Lücke anders ist

Die meisten Web-Schwachstellen stecken in einem bestimmten Plugin oder einer Anwendung. PHP2Shell steckt in PHP selbst, genauer im Code, der eingehende Anfragen verarbeitet. Das bedeutet:

• Jede PHP-Installation, die Webanfragen beantwortet, ist betroffen, darunter PHP-FPM, Apache mit mod_php und php-cgi.

• Standardkonfigurationen sind verwundbar.

• Ältere Versionen sind der schwierigste Fall. Für PHP 7.4, 8.0 und 8.1 gibt es nur Backports im Quellcode, die man selbst kompilieren oder von seiner Distribution beziehen muss. Für PHP 7.3 und älter gibt es überhaupt keinen Fix. Dabei läuft ein großer Teil der PHP-Websites noch auf PHP 7 oder älter.

Für Entscheider: drei Maßnahmen in dieser Woche

1. Bestandsaufnahme anfordern. Welche öffentlichen Websites, internen Tools und Appliances von Drittanbietern nutzen PHP? Appliances und gehostete Produkte werden gern übersehen.

2. Patchen zur Priorität machen. Das ist kein Thema für das nächste reguläre Wartungsfenster.

3. Einen Plan für alles, was sich nicht schnell patchen lässt. Altanwendungen auf alten PHP-Versionen brauchen eine Entscheidung: aktualisieren, isolieren oder vom Netz nehmen.

Für technische Teams: patchen und absichern

Gepatchte Versionen

Starten Sie die PHP-Worker nach dem Update neu, damit kein Prozess den alten Code weiter ausführt.

Wenn Sie heute nicht patchen können

• Deaktivieren Sie session.upload_progress.enabled in der php.ini oder im PHP-FPM-Pool.

• Prüfen Sie memory_limit und post_max_size.

• Auf Websites ohne Datei-Upload können Sie erwägen, multipart/form-data-Anfragen bereits am Webserver abzulehnen. Vorher testen: Upload- und Checkout-Formulare können dadurch ausfallen.

• Für kritische Systeme, die ungepatcht bleiben, ist eine statische Wartungsseite oder das Abschalten des Servers weiterhin die sicherste Option.

Die Rolle von CYBERDEFENSE.AI

Um es klar zu sagen: Keine WAF ersetzt den Patch. PHP2Shell wird in der Anfrageverarbeitung von PHP selbst ausgelöst, und genau dort gehört die Korrektur hin.

Eine präventive Schutzschicht verringert das Risiko zwischen Veröffentlichung und Behebung, also genau in der Phase, in der Angreifer am schnellsten sind. CYBERDEFENSE.AI wartet nicht darauf, dass jemand eine Signatur schreibt. Die Plattform analysiert Verhalten in Echtzeit und blockiert, was nicht nach einem legitimen Besucher aussieht:

• automatisierte Scanner, die Tausende Websites nach verwundbaren PHP-Servern absuchen,

• auffällige Anfragemuster, die nicht zur normalen Nutzung Ihrer Anwendung passen,

• IP-Adressen, die auf der Plattform bereits durch bösartige Aktivitäten aufgefallen sind.

So gewinnen Ihre Teams Zeit, um sauber und in der richtigen Reihenfolge zu patchen, statt nachts zu improvisieren.

Das Wichtigste in Kürze

• PHP2Shell betrifft PHP selbst, nicht eine einzelne Anwendung. Gehen Sie davon aus, dass Sie betroffen sind.

• Aktualisieren Sie auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 und starten Sie die Worker neu.

• Sofortmaßnahmen verschaffen Zeit, schließen die Lücke aber nicht.

• Eine präventive WAF senkt das Risiko, während Sie patchen. Sie ist eine zusätzliche Schutzschicht, kein Ersatz.