# Cloudflare-Schutzregeln gegen PHP2Shell: Was sie leisten und was nicht

> Cloudflare schützt seit dem 21.10. mit WAF-Regeln gegen PHP2Shell. Was die Regeln abdecken, wo sie umgangen werden können und was Sie jetzt prüfen sollten.

Quelle: https://phpsos.de/blog/cloudflare-waf-php2shell/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kurz gesagt:** Cloudflare hat laut eigenen Angaben seit dem 21. Oktober 2026, 03:02 UTC, Schutzregeln gegen PHP2Shell aktiv, auch für Kunden im kostenlosen Tarif. Die Regeln senken das Risiko für Verkehr, der über Cloudflare läuft. Sie wirken nicht, wenn der Ursprungsserver direkt erreichbar ist, und sie ersetzen das PHP-Update nicht. Wer Cloudflare nutzt, sollte Regelmodus, Ursprungsschutz und Patchstand prüfen.

## Der Aufhänger: Schutz schon vor dem Patch

Cloudflare war bei PHP2Shell ungewöhnlich früh dran. Laut Cloudflare-Blog liefen die Schutzregeln bereits mehrere Stunden vor der offiziellen Veröffentlichung der PHP-Updates um 14:00 UTC. Cloudflare berichtete außerdem, Angriffsversuche auf Kunden beobachtet zu haben, und dass Angreifer ihre Muster veränderten, um die Regeln zu umgehen.

Viele Betreiber haben daraus geschlossen: „Wir sind hinter Cloudflare, also sind wir geschützt.“ Das stimmt nur zum Teil. Dieser Beitrag erklärt, was die Regeln tatsächlich abdecken. Eine allgemeine Abwägung zwischen Firewall und Update bietet der Beitrag [WAF oder Update?](https://phpsos.de/blog/waf-oder-update/).

## Was Cloudflare gegen PHP2Shell ausgerollt hat

Nach Angaben im Cloudflare-Blog gibt es drei Bausteine:

| Tarif | Schutz laut Cloudflare | Was Sie tun sollten |
|---|---|---|
| Free | neue Regeln im Managed Free Ruleset, automatisch aktiv | prüfen, dass die Domain über Cloudflare läuft |
| Pro, Business, Enterprise | passende Regeln im Managed Ruleset | sicherstellen, dass das Ruleset auf „Block“ steht |
| alle Tarife | Standardregel in der neuen Response-Firewall | nichts abschalten, Ereignisse beobachten |

Der dritte Baustein ist neu. Cloudflare nennt ihn „full transaction detection“: Die WAF betrachtet nicht nur die Anfrage, sondern auch die Antwort des Servers. Der Grund laut Cloudflare: Die Anfrage allein reicht nicht immer, um einen Angriff sicher von normalem Verkehr zu unterscheiden. PHP2Shell ist der erste Einsatz dieser Funktion in den verwalteten Regeln.

## Die Grenzen der Cloudflare-Regeln

So hilfreich die Regeln sind, sie haben klare Grenzen, die Cloudflare zum Teil selbst benennt:

- **Nur Verkehr über Cloudflare:** Die Regeln prüfen, was durch Cloudflare fließt. Ist der Ursprungsserver unter seiner IP-Adresse direkt erreichbar, kann ein Angreifer den Schutz umgehen.
- **Kein Rückgängigmachen:** Laut Cloudflare kann eine Regel auf der Antwortseite die Antwort zurückhalten, aber nicht ungeschehen machen, was auf dem Server bereits passiert ist.
- **Wechselnde Angriffsmuster:** Cloudflare passt Regeln laufend an, weil Angreifer ihre Anfragen verändern. Zwischen neuer Variante und neuer Regel kann eine Lücke liegen.
- **Kein Ersatz für das Update:** Cloudflare empfiehlt ausdrücklich, PHP trotz WAF zu aktualisieren. Auch ein Update von Anwendungscode oder Plugins behebt die Lücken nicht.
- **Sonderfall CVE-2026-115560:** Laut Cloudflare-Ergänzung vom 23. Oktober greift die Regel nicht, wenn der Name für Session-Upload-Progress in der Konfiguration geändert wurde. Mehr zu dieser Meldung unter [CVE-2026-115560](https://phpsos.de/php2shell/cve-2026-115560/).

### Was blockierte Anfragen aussagen und was nicht

Viele Kunden schauen nach der Meldung in ihre Sicherheitsereignisse und finden dort blockierte Anfragen. Das zeigt zunächst nur, dass Ihre Domain geprüft wurde und die Regel gegriffen hat. Ein Einbruch ist damit nicht belegt. Umgekehrt ist eine leere Ereignisliste keine Entwarnung: Lief ein Angriff direkt auf den Ursprungsserver oder vor dem 21. Oktober, taucht er bei Cloudflare gar nicht auf.

Verlässlicher ist der Abgleich mit den Logs des Webservers selbst. Anfragen, die dort ankommen, aber nicht von Cloudflare-Adressen stammen, deuten auf einen direkten Zugang hin. Sichern Sie diese Logs ab dem 20. Oktober, wie es die Fachpresse rät. Cloudflare weist außerdem darauf hin, dass Beschränkungen für Uploads das Risiko verringern können, das PHP-Update aber nicht ersetzen.

> **Wichtig:**
> Die häufigste Schwachstelle hinter Cloudflare ist nicht die Regel, sondern der Weg daran vorbei: ein Ursprungsserver, der unter seiner IP-Adresse oder über eine nicht geschützte Subdomain direkt antwortet.

## Prüfliste für Cloudflare-Kunden

Diese Schritte können Sie oder Ihr Dienstleister kurzfristig erledigen:

1. **Tarif und Regelmodus prüfen:** Bei bezahlten Tarifen im Dashboard kontrollieren, dass das Managed Ruleset im Modus „Block“ aktiv ist.
2. **Sicherheitsereignisse ansehen:** Unter den Security Events prüfen, ob blockierte Anfragen auftauchen. Das zeigt, ob Ihre Domains bereits Ziel waren.
3. **DNS-Einträge durchgehen:** Jeder Eintrag, der auf den Webserver zeigt, aber nicht über Cloudflare läuft, ist ein möglicher Umweg. Typisch sind Subdomains für Staging, FTP oder Mail auf demselben Server.
4. **Ursprung abschotten:** Den Webserver so konfigurieren, dass er HTTP und HTTPS nur von Cloudflare annimmt, etwa per Firewall mit den von Cloudflare veröffentlichten Adressbereichen oder über einen Tunnel. Wie das allgemein geht, beschreibt der Beitrag [Firewall für Webserver](https://phpsos.de/blog/firewall-fuer-webserver/).
5. **Direkten Zugriff testen:** Von außen prüfen, ob der Ursprung ohne Cloudflare antwortet.
6. **PHP aktualisieren und neu starten:** Die Regeln sind die zweite Linie. Die erste ist PHP auf einem behobenen Stand mit [Neustart aller PHP-Prozesse](https://phpsos.de/php2shell/php-fpm-neustart/).

Für Schritt 5 genügt ein harmloser Test, der nur die Kopfzeilen abfragt. Die IP-Adresse ist ein Platzhalter für Ihren Ursprungsserver:

```bash
# Antwortet der Ursprungsserver direkt, an Cloudflare vorbei?
curl -sI --resolve www.example.de:443:203.0.113.10 https://www.example.de/
```

Kommt hier eine reguläre Antwort Ihrer Website, ist der Ursprung direkt erreichbar und der Cloudflare-Schutz umgehbar.

## Wie hilft PHP SOS konkret?

- **Konfigurationsprüfung:** Wir prüfen Regelmodus, DNS-Einträge und den direkten Zugang zum Ursprungsserver.
- **Ursprung absichern:** Wir beschränken den Webserver auf Verkehr über Cloudflare, ohne Ihre Website zu unterbrechen.
- **Patch und Nachweis:** Wir aktualisieren PHP, starten alle Prozesse neu und dokumentieren den Stand.
- **Ereignisse auswerten:** Wir sichten blockierte Anfragen und gleichen sie mit den Server-Logs ab.

Wie wir WAF-Regeln und Übergangsmaßnahmen kombinieren, beschreibt [WAF und virtuelles Patching](https://phpsos.de/leistungen/waf-virtuelles-patching/).

## Fazit

Die Cloudflare-Regeln gegen PHP2Shell sind ein echter Gewinn, besonders weil sie früh und auch im kostenlosen Tarif kamen. Sie sind aber ein Schutzschild vor der Tür, kein Schloss an der Tür. Wer hinter Cloudflare sitzt, sollte drei Dinge sicherstellen: Regeln im Block-Modus, kein Weg am Proxy vorbei und PHP auf einem behobenen Stand.


## Häufige Fragen

**Bin ich mit dem kostenlosen Cloudflare-Tarif gegen PHP2Shell geschützt?**  
Laut Cloudflare erhalten auch Free-Kunden die Schutzregeln automatisch. Sie wirken aber nur für Verkehr, der über Cloudflare läuft, und ersetzen nicht das PHP-Update auf dem Server. Ist der Ursprungsserver direkt erreichbar, greift der Schutz nicht.

**Was muss ich bei bezahlten Cloudflare-Tarifen einstellen?**  
Cloudflare rät Kunden mit Pro-, Business- und Enterprise-Tarif zu prüfen, dass das Managed Ruleset im Modus Block läuft. Steht es nur auf Protokollieren, werden Angriffe zwar erfasst, aber nicht aufgehalten.

**Was ist full transaction detection?**  
Eine neue Funktion der Cloudflare-WAF, die nicht nur die Anfrage, sondern auch die Antwort des Servers betrachtet. So lässt sich erkennen, ob ein Angriffsversuch Wirkung zeigt, und die Antwort kann zurückgehalten werden. Was auf dem Server bereits ausgeführt wurde, macht sie laut Cloudflare nicht rückgängig.

**Deckt Cloudflare auch CVE-2026-115560 ab?**  
Cloudflare hat seinen Beitrag am 23. Oktober zu CVE-2026-115560 ergänzt. Laut Cloudflare greift die zugehörige Regel nicht, wenn der Name für Session-Upload-Progress in der PHP-Konfiguration geändert wurde. Unabhängig davon empfiehlt php.net, session.upload_progress.enabled=0 zu setzen.

## Quellen

- [Cloudflare-Blog: Cloudflare deploys protections against php2shell vulnerability](https://blog.cloudflare.com/php-vulnerabilities-waf-protection/)
- [Cloudflare-Blog: Introducing full transaction detection for Cloudflare WAF](https://blog.cloudflare.com/full-transaction-waf/)
- [php.net: Sicherheitsmeldungen](https://www.php.net/)