Kurz gesagt: WAF statt Update funktioniert bei PHP2Shell nicht. Eine Web Application Firewall, also ein Filter vor der Website, prüft Anfragen und kann bekannte Angriffsmuster blocken. Die Lücke selbst steckt aber im PHP-Interpreter und verschwindet erst mit dem Update und dem Neustart aller PHP-Prozesse. Eine WAF ist eine sinnvolle zusätzliche Schicht und eine Brücke für wenige Tage, nicht die Lösung.
Warum die Frage gerade jetzt so oft gestellt wird
Viele Betreiber haben in der PHP2Shell-Woche eine scheinbar gute Nachricht gelesen: Cloudflare hat laut eigenen Angaben seit dem 21.10.2026, 03:02 UTC, Schutzregeln aktiv, auch für Kunden im kostenlosen Tarif. Wer ohnehin hinter Cloudflare oder einer anderen WAF steht, fragt sich verständlicherweise, ob das Update dann noch eilt.
Die ehrliche Antwort lautet ja. Cloudflare selbst schränkt ein: Regeln anhand der Anfragedaten allein genügen nicht, deshalb prüft der Dienst zusätzlich die Antwort des Servers. Cloudflare hat außerdem veränderte Angriffsmuster beobachtet. Und der Schutz wirkt nur für Verkehr, der tatsächlich über Cloudflare läuft. Die Einzelheiten zu diesem Anbieter beschreibt Cloudflare-Schutzregeln gegen PHP2Shell. Hier geht es um die grundsätzliche Abwägung, unabhängig vom Anbieter.
Was eine WAF sieht und was ein Update ändert
Eine WAF sitzt vor der Anwendung. Sie sieht jede Anfrage, vergleicht sie mit Regeln und lässt sie durch, blockt sie oder protokolliert sie. Sie weiß nicht, wie PHP die Anfrage intern verarbeitet. Die beiden PHP2Shell-Lücken entstehen aber genau dort: CVE-2026-109618 bei einem Out-of-Memory-Zustand, während Anfragedaten nur teilweise initialisiert sind, CVE-2026-109619 durch internen Zustand, der nach einer Anfrage im selben Worker bestehen bleibt.
Das Update korrigiert diesen Code. Danach ist die Ursache beseitigt, egal wie eine Anfrage aussieht. Wer verstehen will, an welcher Stelle im Ablauf einer Anfrage das passiert, findet die Grundlagen unter Der Request-Lebenszyklus in PHP.
WAF statt Update: der ehrliche Vergleich
| Kriterium | Web Application Firewall | PHP-Update mit Neustart |
|---|---|---|
| Was wird behoben? | Nichts, bekannte Muster werden abgefangen | Die Ursache im PHP-Interpreter |
| Schutz bei neuen Angriffsvarianten | Nur, wenn Regeln rechtzeitig angepasst werden | Ja, die Lücke existiert nicht mehr |
| Umgehung möglich? | Ja, etwa über direkte Erreichbarkeit des Ursprungsservers | Nein, sofern alle PHP-Prozesse neu gestartet sind |
| Geschwindigkeit | Oft sofort aktiv | Abhängig von Version, Zugang und Wartungsfenster |
| Nebenwirkungen | Fehlalarme, gestörte Formulare oder Uploads | Selten, bei Versionssprüngen Kompatibilitätstests nötig |
| Nutzen bei der nächsten Lücke | Hoch, wenn gepflegt | Keiner, jede Lücke braucht ihr eigenes Update |
| Hilft bei PHP 8.1 und älter? | Als Übergang | Nur über Backport oder Migration |
Die Tabelle zeigt, warum beide Maßnahmen zusammengehören. Die WAF ist schnell und breit, aber nie vollständig. Das Update ist vollständig, aber nur für eine bestimmte Lücke und nicht immer sofort möglich.
Ein Punkt wird in der Praxis oft übersehen: Eine WAF verändert das Verhalten der Website. Strenge Regeln können legitime Bestellungen, Kontaktformulare oder Datei-Uploads blocken, ohne dass es jemand sofort merkt. Wer eine WAF in der Krise scharf schaltet, sollte deshalb die wichtigsten Abläufe der Website einmal selbst durchklicken und die Protokolle der ersten Tage auf geblockte, aber berechtigte Anfragen prüfen.
So kombinieren Sie beides sinnvoll
- Sofort: Prüfen, ob eine WAF vorhanden ist und ob die passenden Regeln aktiv sind. Bei Cloudflare in bezahlten Tarifen laut Anbieter das Managed Ruleset auf Block stellen.
- Sofort: Sicherstellen, dass der Ursprungsserver nur über die WAF erreichbar ist, etwa per Firewall-Freigabe nur für deren Adressbereiche. Sonst läuft der Schutz ins Leere.
- Innerhalb des nächsten Wartungsfensters: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren oder den bestätigten Backport der Distribution einspielen.
- Direkt danach: Alle PHP-Worker und Prozesse neu starten und kontrollieren, dass kein alter Prozess mehr läuft. Neue Dateien allein reichen nicht; mehr dazu unter Nach dem Update: PHP-FPM und alle Worker neu starten.
- Danach: WAF-Regeln behalten, Fehlalarme auswerten und Ausnahmen gezielt setzen statt Regeln pauschal abzuschalten.
Mit einer eigenen WAF auf Basis von ModSecurity und dem OWASP Core Rule Set lässt sich Ähnliches erreichen; die Grundlagen beschreibt ModSecurity und OWASP Core Rule Set einsetzen. Eine Sonderform ist das von Fachautoren vorgeschlagene Filtern von Upload-Anfragen außerhalb echter Upload-Pfade. Es ist inoffiziell, kann Formulare brechen und gehört nur nach Test in den Betrieb.
Weder WAF noch Update entfernen Schadsoftware, die vorher eingeschleust wurde. Prüfen Sie nach dem Patch, ob seit dem 17.10.2026 Auffälligkeiten aufgetreten sind.
Wann Sie keine WAF brauchen und wann keinen Dienstleister
Eine WAF ist nicht für jede Website Pflicht. Eine kleine Firmenwebsite beim Hoster, der PHP zeitnah patcht und das bestätigt, ist ohne eigene WAF oft ausreichend geschützt, wenn CMS und Plugins aktuell sind. Auch wer seinen Server binnen kurzer Zeit selbst aktualisieren kann, braucht die WAF nicht als Brücke.
Sinnvoll wird sie bei Shops, Portalen und Anwendungen mit vielen Formularen, bei Altsystemen, die nicht sofort aktualisiert werden können, und dort, wo mehrere Websites zentral geschützt werden sollen. Einen Dienstleister brauchen Sie dafür nur, wenn Einrichtung, Tests und laufende Pflege intern nicht abgedeckt sind.
Wie hilft PHP SOS konkret?
- Wir prüfen, ob Ihre WAF tatsächlich vor allen Zugängen sitzt und ob der Ursprungsserver direkt erreichbar ist.
- Wir richten Regeln ein oder passen sie an und testen Formulare, Uploads und Schnittstellen auf Nebenwirkungen.
- Wir spielen das PHP-Update ein, starten alle Prozesse neu und dokumentieren den Stand.
- Wo das Update dauert, überbrücken wir mit WAF und virtuellem Patching und einem festen Termin für den echten Patch.
Fazit
Die Frage „WAF oder Update“ ist falsch gestellt. Das Update schließt die Lücke, die WAF verschafft Zeit und fängt vieles andere ab. Wer nur auf die WAF setzt, verlässt sich auf Regeln, die Angreifer umgehen können. Wer nur patcht, steht bei der nächsten Lücke wieder ohne Brücke da.
Häufige Fragen
Reicht eine WAF als Schutz gegen PHP2Shell?
Nein. Eine WAF prüft den Datenverkehr und kann bekannte Angriffsmuster blocken. Die Lücke selbst steckt im PHP-Interpreter und bleibt bestehen, bis PHP aktualisiert und neu gestartet ist. Cloudflare betont ausdrücklich, dass seine Regeln das Update nicht ersetzen.
Bin ich hinter Cloudflare automatisch geschützt?
Nur für den Verkehr, der tatsächlich über Cloudflare läuft. Ist der Ursprungsserver direkt aus dem Internet erreichbar, wird der Schutz umgangen. Bei bezahlten Tarifen sollten Sie laut Cloudflare prüfen, dass das Managed Ruleset auf Block steht.
Lohnt sich eine WAF nach dem Update noch?
Oft ja. Eine WAF kann Massenscans, bekannte Angriffe auf Plugins und Missbrauch von Login-Seiten abfangen und verschafft bei der nächsten Lücke Zeit. Sie braucht aber Pflege und Tests, sonst stören Fehlalarme den Betrieb.
Was ist virtuelles Patching?
Damit ist gemeint, eine Schwachstelle vorübergehend durch Regeln vor der Anwendung abzuschirmen, statt den Code zu ändern. Es ist eine Brücke bis zum echten Update, kein Ersatz.