PHP2Shell: kritische PHP-Lücken jetzt patchen

Am 21. Oktober 2026 hat das BSI vor zwei kritischen Schwachstellen in PHP gewarnt und die Lage mit der Kritikalität 3 von 4 („Orange“) eingestuft: Maßnahmen müssen unverzüglich ergriffen werden. Betroffen sind nach aktuellem Stand alle bekannten PHP-Versionen, zurück bis mindestens PHP 5. Angreifer könnten ohne Anmeldung und ohne Zutun der Nutzer Schadcode auf Webservern ausführen. Die Patches erschienen am selben Tag um 16 Uhr deutscher Zeit, und das BSI rechnet mit einer breiten Ausnutzung innerhalb weniger Stunden. Patchen hat jetzt oberste Priorität.

Nur lässt sich der Patch längst nicht überall sofort einspielen. Genau für diese Zeit hat Cloudflare am selben Tag Notfall-Regeln für seine Web Application Firewall ausgerollt. Wo die Managed Rules für eine Webanwendung aktiv sind, senken sie das Risiko ab sofort, ohne Eingriff am Server.

Was über PHP2Shell bekannt ist

Die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619 sind jeweils mit 9,2 von 10 Punkten nach CVSS 4.0 bewertet (CVE und CVSS einfach erklärt). In Berichten heißen sie in Anlehnung an Log4Shell auch „PHP2Shell“. Laut PHP-Projekt betrifft die erste Lücke die Behandlung von Speichermangel: Wird PHP unterbrochen, während interne Anfragedaten erst teilweise initialisiert sind, kann die spätere Aufräumroutine diese Daten fälschlich als gültig behandeln. Bei der zweiten überlebt anfragebezogener interner Zustand, obwohl sein Speicher bereits freigegeben ist. Eine spätere Anfrage im selben Worker kann ihn dann verwenden.

Gefährdet sind alle PHP-Installationen, die Webanfragen verarbeiten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Projekt das Risiko bei mod_php ein. Dort wurde ein Exploit gezeigt, bei dem eine Anfrage ohne Anmeldung den Angriff auslöst, bevor überhaupt Anwendungscode läuft. Zum Zeitpunkt der Warnung kannte das BSI keine bestätigten Angriffe, wohl aber unbestätigte Berichte über existierende Exploits.

Sofort wirksam: WAF-Regeln von Cloudflare

Cloudflare hat Notfall-Releases für das Cloudflare Managed Ruleset und das kostenlose Cloudflare Free Ruleset veröffentlicht. Beide erhalten neue Regeln der Gruppe „Generic Rules - Anomalous Execution“, die auffällige Anfragemuster erkennen und mit der Aktion „Block“ ausgeliefert werden. Weil die WAF am Rand des Cloudflare-Netzes prüft, greifen die Regeln, bevor eine Anfrage den Webserver erreicht. Am PHP-System selbst muss dafür nichts geändert werden.

Das zählt gerade jetzt, denn für viele Systeme gibt es noch keinen Patch, der sich einspielen lässt. PHP 8.1 und älter erhält vom PHP-Projekt keine offiziellen Updates mehr. Pakete aus Distributionen und Drittquellen folgen teils später, das verbreitete Repository rpms.remirepo.net etwa hat am Tag der Veröffentlichung keine Updates bereitgestellt. Appliances wie pfSense oder OPNsense brauchen neue Firmware vom Hersteller, Container-Images müssen neu gebaut werden. Diese Lücke zwischen Patch und Einspielen kann die WAF überbrücken.

Ein Ersatz für das Update ist sie trotzdem nicht. Cloudflare nennt in den Changelogs keine CVE-Nummern, und auch das BSI schreibt, eine WAF könne eine Ausnutzung nur verhindern, wenn passende Erkennungen vorhanden und aktiv sind. Drei Punkte sollten deshalb sitzen:

1. Die Managed Rulesets sind für alle betroffenen Zonen aktiv, und die neuen Regeln werden nicht durch Ausnahmen oder geänderte Aktionen entschärft.
2. Der Ursprungsserver ist nur über Cloudflare erreichbar, etwa per Cloudflare Tunnel oder einer Firewall, die nur Cloudflare-Adressen zulässt. Sonst umgehen Angreifer die WAF über die direkte Adresse.
3. Die Firewall-Ereignisse werden beobachtet, damit Treffer auf die neuen Regeln und mögliche Fehlalarme früh auffallen.

Wie eine WAF eine Lücke bis zum Patch abfängt, haben wir bereits am Beispiel der WordPress-Lücke wp2shell beschrieben.

Wie KAEMI sofort hilft

Als Cloudflare Authorized Service Delivery Partner können wir sofort unterstützen, auch dort, wo das Update noch Tage dauert. Webanwendungen, die noch nicht hinter Cloudflare liegen, bringen wir kurzfristig dorthin: Zone einrichten, Verkehr über Cloudflare leiten, Managed Ruleset aktivieren und den Ursprungsserver abschotten. Bei bestehenden Cloudflare-Umgebungen prüfen wir Regeln, Ausnahmen und Erreichbarkeit der Server. Parallel planen wir mit Ihnen die Updates, damit die WAF eine Überbrückung bleibt und kein Dauerzustand wird.

Mehr zu unserem Leistungsangebot steht auf der Seite Application Security. Für eine schnelle Abstimmung erreichen Sie uns über das Kontaktformular, Bestandskunden über den Support rund um die Uhr.

Warum Stunden zählen

PHP steckt in einem großen Teil des Webs, entsprechend breit wirken kritische PHP-Lücken. Das BSI nennt WordPress, Drupal, TYPO3, Joomla, Magento und Nextcloud, aber auch Firewall-Produkte wie pfSense und OPNsense sowie Komponenten proprietärer Software. Dazu kommt das Tempo. Mit KI-gestützten Werkzeugen lassen sich Patches inzwischen schnell analysieren und in Exploits übersetzen. Zwischen Veröffentlichung und erster Angriffswelle liegen deshalb eher Stunden als Tage. Wie stark KI diese Zeit verkürzt, zeigt unser Beitrag Wenn KI die Angriffskette übernimmt.

Was jetzt zu tun ist

Unsere Empfehlung für alle, die PHP-Systeme betreiben:

1. Betroffene Systeme identifizieren: Webserver, Container-Images und Appliances mit PHP erfassen, auch Systeme, die PHP nur als Komponente mitbringen.
2. WAF-Schutz sofort aktivieren beziehungsweise prüfen, damit die Zeit bis zum Update abgesichert ist.
3. Sicherheitsupdates einspielen, sobald sie für das jeweilige System verfügbar sind: PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Wer PHP über die Paketverwaltung der Linux-Distribution bezieht, prüft die dort bereitgestellten Backport-Versionen, Docker-Images werden neu gebaut. Den Stand anschließend mit php -v gegen das Advisory abgleichen.
4. Altversionen gesondert behandeln: Für PHP 7.4, 8.0 und 8.1 gibt es minimale Backports im Quellcode, ansonsten helfen nur LTS-Anbieter oder ein Upgrade.
5. Exponierte Webserver verstärkt überwachen, vor allem auf ungewöhnliche Prozesse, abstürzende Worker und auffällige Anfragen.

Lässt sich ein System nicht kurzfristig aktualisieren, nennt das PHP-Projekt zusätzlich Übergangsmaßnahmen auf dem Server, etwa ein niedriges post_max_size oder das Abschalten von session.upload_progress.enabled. Sie verkleinern einzelne Angriffswege, machen eine Installation aber nicht sicher. Als letzte Option bringt das BSI ins Spiel, den Webserver bis zum Patch vom Internet zu trennen.

Quellen: BSI, Pressemitteilung „PHP: BSI warnt vor kritischen Schwachstellen“ und Cybersicherheitswarnung BITS-H 2026-297981-1032 (21. Oktober 2026); PHP-Projekt, Security Advisory zu CVE-2026-109618 und CVE-2026-109619 (21. Oktober 2026); Cloudflare-Changelog, „WAF Release 2026-10-21 Emergency“ für das Managed und das Free Ruleset.