Eine WAF verschafft Zeit, bis PHP gepatcht ist

Was Cloudflare veröffentlicht hat

Am 21. Oktober 2026 hat Cloudflare verwaltete WAF-Regeln für diese beiden CVEs veröffentlicht. Laut Cloudflare gilt:

• Die Regeln heißen "Generic Rules - Anomalous Execution - 1" bis "- 7".
• Sie liegen im Managed Free Ruleset (Free-Tarif, standardmäßig aktiv) und im Managed Ruleset (Pro, Business und Enterprise).
• Die Aktion ist Block.
• Eine Regel auf der Antwortseite, die standardmäßig blockiert, kam in das Ruleset Managed Response Firewall Default.

Die Abhilfe greift an Cloudflares Edge. PHP auf Ihrem Origin bleibt ungepatcht. Details, Belege und Links sammeln wir auf der Seite zur Cloudflare-WAF.

Cloudflare berichtet außerdem, Angriffstraffic gegen eigene Kunden gesehen zu haben, und dass Angreifer ihre Payloads angepasst haben, um an WAF-Regeln vorbeizukommen. Das sind Cloudflares eigene Telemetriedaten; Mengen oder Indikatoren wurden nicht veröffentlicht. Praktisch heißt das: Eine Regel, die die Anfrageform von heute blockiert, kann die von morgen übersehen.

Warum der Origin alle anderen abweisen muss

Eine WAF sieht nur Traffic, der durch sie hindurchgeht. Ihr Server hat weiterhin eine IP-Adresse, und Angreifer finden sie in alten DNS-Einträgen, Certificate-Transparency-Logs, Mail-Headern oder bei einem Scan des gesamten Internets. Antwortet der Origin auf Port 80 und 443 jedem, trifft eine Anfrage direkt an diese IP nie auf die WAF.

Eine WAF vor einem offenen Origin filtert also nur die Angreifer, die freiwillig über sie gehen. Mit den folgenden Schritten weist der Origin direkte Verbindungen ab.

Den Origin auf Cloudflare beschränken

Cloudflares Anleitung nennt mehrere Methoden und bewertet sie. Von der stärksten zur schwächsten:

1. Cloudflare Tunnel

cloudflared läuft auf Ihrem Server und baut ausgehende Verbindungen zu Cloudflare auf. Danach sperren Sie in der Firewall jeden eingehenden Webtraffic, sodass nur noch der Tunnel die Site erreicht. Es bleibt kein öffentlicher Listener, den man angreifen könnte. Einrichtung: Cloudflare-Tunnel-Doku. Cloudflare weist darauf hin, dass Authenticated Origin Pulls für getunnelte Hostnamen nicht gilt, weil es keinen eingehenden Listener gibt.

2. Authenticated Origin Pulls (mTLS)

Cloudflare legt Ihrem Origin ein Client-Zertifikat vor, und der Origin lehnt Verbindungen ohne Zertifikat ab. Voraussetzung ist der SSL/TLS-Modus Full oder Full (strict); es funktioniert in allen Tarifen. Das gemeinsame Cloudflare-Zertifikat belegt nur, dass die Anfrage aus Cloudflares Netz kommt. Um zu belegen, dass sie über Ihr Konto kam, laden Sie ein eigenes Zertifikat hoch (auf Zonen- oder Hostname-Ebene). Anleitungen für die Modi global, Zone und Hostname stehen in der Cloudflare-Doku.

Unter nginx sieht die Origin-Seite so aus, mit der CA-Datei an dem Ort, den die Anleitung vorgibt:

ssl_client_certificate /etc/nginx/certs/cloudflare.crt;
ssl_verify_client on;

Unter Apache:

SSLVerifyClient require
SSLCACertificateFile /path/to/origin-pull-ca.pem

Testen Sie von einem externen Rechner mit curl -k https://ORIGIN_IP/ -H 'Host: example.com'. Der Handshake sollte fehlschlagen.

3. Firewall-Allowlist der Cloudflare-IP-Bereiche

Cloudflare veröffentlicht seine Bereiche unter cloudflare.com/ips, als reine Listen unter https://www.cloudflare.com/ips-v4 und https://www.cloudflare.com/ips-v6. Die Cloudflare-Doku gibt für iptables dieses Muster vor: Webtraffic aus jedem Bereich annehmen, dann allen übrigen Webtraffic verwerfen.

for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  iptables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  ip6tables -I INPUT -p tcp -m multiport --dports http,https -s "$ip" -j ACCEPT
done
iptables  -A INPUT -p tcp -m multiport --dports http,https -j DROP
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROP

Lesen Sie die Listen, bevor Sie das ausführen, und stellen Sie sicher, dass Ihr eigener SSH- und Monitoring-Zugang nicht über diese Ports läuft. Cloudflare stuft diese Methode unter den ersten beiden ein, weil sie "vulnerable to IP spoofing" sei. Die Bereiche ändern sich selten, und neue werden vor der Nutzung angekündigt. Planen Sie trotzdem eine regelmäßige Aktualisierung ein. Cloud-Anbieter haben für dieselbe Aufgabe eigene Security-Group-Werkzeuge.

Auf Lecks prüfen

Prüfen Sie Nur-DNS-Einträge auf die Origin-IP (A-Records für Subdomains wie mail, ftp oder direct, SPF-Einträge), lassen Sie Mail nicht über den Webserver laufen und erwägen Sie eine neue Origin-IP, falls die alte je öffentlich war. Cloudflares Anleitung zum Origin-Schutz behandelt diese Punkte.

Andere Firewalls: was die Quellen sagen

Mehrere Produkte arbeiten auf Host- oder Anwendungsebene. Die Tabelle nennt nur, was unsere Quellen über sie sagen.

Keines dieser Produkte ändert das PHP-Binary. Firewalls auf Plugin-Ebene laufen als PHP-Anwendungscode, und der Angriff über mod_php kann auslösen, bevor überhaupt Anwendungscode läuft. Verlassen Sie sich nicht darauf, dass sie ihn stoppen.

Wie es weitergeht

1. Patchen. Wechseln Sie auf einen korrigierten Build: 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, bei älteren Zweigen auf einen Backport Ihres Anbieters. Für Ihre Distribution oder Ihr Panel siehe /fix.
2. Jeden PHP-Worker neu starten. Ein neues Paket macht den Server erst sicher, wenn die alten Prozesse beendet sind.
3. Von der Webseite aus prüfen, mit Nach dem Patchen.

Wenn Sie heute nicht patchen können, ergänzen Sie die Übergangseinstellungen und lassen Sie WAF und abgeschotteten Origin bestehen.

Zuletzt geprüft am 22. Oktober 2026.