Auf einen Blick

Ihre Systeme

Sind Sie betroffen?

Wenn Sie PHP zur Verarbeitung von Webanfragen einsetzen (PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed) und die Version älter als 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 ist, gehen Sie davon aus, dass Sie betroffen sind. Dazu gehören auch auf PHP basierende Anwendungen wie WordPress, Drupal, Magento und Laravel.

TR7-Produkte

Ist TR7 betroffen?

Nein. TR7-Appliances enthalten keine PHP-Komponente, die HTTP-Anfragen verarbeitet, daher sind TR7-Produkte von diesen Schwachstellen nicht betroffen. Einzelheiten finden Sie unter Ist TR7 betroffen?.

Maßnahmen

Was jetzt zu tun ist

  1. Aktualisieren Sie PHP auf Ihren Webanwendungsservern und starten Sie jeden PHP-Worker neu.
  2. Wenden Sie die unten aufgeführten temporären PHP-Einstellungen auf diesen Servern an, wenn Sie nicht noch heute aktualisieren können.
  3. Wenden Sie bis zum Abschluss des Updates die Einstellungen für den Basisschutz in TR7 WAF-WAAP an; die erste davon ist, Ihre PHP-Anwendungen in den Blocking mode zu versetzen.

Eckdaten

Hinweis-IDTR7-SA-2026-001
NamePHP2Shell
CVEsCVE-2026-109618 (Remotecodeausführung durch Speicherbeschädigung bei Speichererschöpfung),
CVE-2026-109619 (Remotecodeausführung durch veralteten globalen Zustand)
Offizielle SicherheitshinweiseAnkündigung des PHP Security Team
GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
SchweregradCVSS v4.0 9.2, Kritisch (PHP Security Team)
Authentifizierung erforderlichNein
Behobene VersionenPHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
Ältere VersionszweigeDas PHP Security Team hat Quellcode-Backports für PHP 7.4, 8.0 und 8.1 veröffentlicht. Linux-Distributionen stellen eigene gepatchte Pakete bereit.
AusnutzungEs werden Ausnutzungsversuche gemeldet. Eine erfolgreiche Kompromittierung war bis zum 22. Oktober 2026 nicht öffentlich bestätigt.
CISA KEVIm Katalog vom 21. Oktober 2026 nicht aufgeführt

Was ist passiert

  • 20. Oktober 2026 Details zu den Schwachstellen wurden vor der koordinierten Veröffentlichung öffentlich bekannt.
  • 21. Oktober 2026 Das PHP-Projekt veröffentlichte behobene Versionen sowie die Sicherheitshinweise GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp.
  • 21. bis 22. Oktober 2026 Ausnutzungsversuche wurden gemeldet, und öffentlicher Proof-of-Concept-Code tauchte auf.

So funktioniert der Angriff

Beide Schwachstellen liegen in PHP selbst, nicht im Anwendungscode. Der Angriff erfolgt, während PHP die eingehende Anfrage noch liest, bevor auch nur eine Zeile Ihrer Anwendung ausgeführt wird. Ein Update von WordPress, eines Plugins oder Ihres eigenen Codes behebt das Problem nicht.

  • CVE-2026-109618 missbraucht den Moment, in dem PHP der Speicher ausgeht. Angreifer senden Anfragen, die PHP beim Parsen von Formulardaten und Datei-Uploads zu hohem Speicherverbrauch zwingen, sodass PHP in einem unsicheren Zustand anhält.
  • CVE-2026-109619 hinterlässt nach einer Anfrage veraltete Daten in einem PHP-Worker, und eine zweite Anfrage an denselben Worker verwendet sie. Ein dokumentierter Weg nutzt die PHP-Funktion session upload progress, die standardmäßig aktiviert ist und durch ein Formularfeld namens PHP_SESSION_UPLOAD_PROGRESS ausgelöst wird.

Da die Anfragen, die diese Angriffe transportieren, überwiegend Anfragen vom Typ multipart/form-data (Datei-Upload), große Request-Bodys und wiederholte Anfragen sind, kann eine Web Application Firewall viele davon erkennen und einschränken. Was im Speicher von PHP geschieht, kann sie nicht sehen.

Ist TR7 betroffen?

Diese Schwachstellen liegen in der eigenen Anfrageverarbeitungsschicht von PHP und betreffen Anwendungsserver, auf denen PHP läuft. TR7-Appliances enthalten keine PHP-Komponente, die HTTP-Anfragen verarbeitet, daher sind TR7-Produkte von diesen Schwachstellen nicht betroffen.

Was Sie jetzt tun sollten

Die Arbeiten betreffen zwei Stellen: Ihre eigenen Webanwendungsserver, auf denen PHP läuft, und TR7 WAF-WAAP. Jeder Abschnitt nummeriert seine Schritte separat.

Auf Ihren Servern

Schritt 1: PHP auf Ihren Webanwendungsservern aktualisieren (die einzige vollständige Behebung)

  1. Aktualisieren Sie PHP auf den Servern, auf denen Ihre Webanwendung läuft, auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12, oder installieren Sie das gepatchte Paket Ihrer Linux-Distribution. Distributionspakete behalten oft die alte Versionsnummer bei; prüfen Sie das Changelog des Pakets auf die CVE-Nummern.
  2. Starten Sie jeden PHP-Worker neu (PHP-FPM-Pools, Apache, LiteSpeed, langlaufende Worker). Laufende Prozesse verwenden den alten Code weiter, bis sie neu gestartet werden.
  3. Erstellen Sie Container-Images neu, die ihr eigenes PHP enthalten. Ein Update des Hosts aktualisiert nicht das PHP innerhalb eines Images.
  4. PHP 8.1 und älter erhalten keine Updates mehr vom PHP-Projekt. Planen Sie ein Upgrade auf einen unterstützten Versionszweig.

Schritt 2: Temporäre PHP-Einstellungen auf Ihren Webanwendungsservern (wenn Sie nicht noch heute aktualisieren können)

Diese Einstellungen werden in der PHP-Konfiguration des Servers vorgenommen, auf dem Ihre Webanwendung läuft (php.ini oder Einstellungen des PHP-FPM-Pools). Das PHP Security Team führt diese Maßnahmen auf. Sie verringern die Gefährdung durch bestimmte Angriffswege, machen eine Installation aber nicht sicher.

EinstellungZweck
session.upload_progress.enabled = 0Entfernt den Angriffsweg über session upload progress bei CVE-2026-109619. Starten Sie alle Worker neu. Das PHP Security Team empfiehlt, die Funktion auch nach dem Patchen deaktiviert zu lassen, wenn Sie sie nicht benötigen.
fatal_error_backtraces = 0 (PHP 8.5)Entfernt den Angriffsweg über Fatal-Error-Backtraces
post_max_size = 8M (ohne Uploads) oder 32M (mit Uploads), mit niedrigerem upload_max_filesizeVerringert die Speichermenge, deren Verbrauch ein Angreifer PHP aufzwingen kann
memory_limit = -1, gesetzt mit php_admin_valueBeseitigt den steuerbaren Fehler beim Erreichen des Speicherlimits. Eine einzelne Anfrage kann dann den gesamten Serverspeicher belegen; verwenden Sie Container- oder cgroup-Limits, niemals RLIMIT_AS oder RLIMIT_DATA

In TR7 WAF-WAAP

Wenn Sie PHP sofort aktualisieren können, ist das die eigentliche Behebung. Wenn nicht, können Sie Ihre PHP-Anwendungen bis zum Abschluss des Updates mit den Sicherheitseinstellungen, die TR7 WAF-WAAP bereits bietet, ohne ein TR7-Update gegen diese Angriffe schützen. Die drei Einstellungen in Schritt 1 bilden den Basisschutz; die zusätzlichen Maßnahmen in Schritt 2 verkleinern die Angriffsfläche weiter, wählen Sie also diejenigen aus, die zu Ihrer Anwendung passen. Nehmen Sie die Einstellungen pro vService vor und testen Sie sie zunächst auf einem nicht produktiven vService.

Schritt 1: Basisschutz

1.1 WAF in den Blocking mode versetzen

Eine WAF, die nur überwacht, stoppt keinen Angriff. Wenn die WAF zum ersten Mal aktiviert wird, startet sie im Learning mode; der Monitor mode zeichnet nur auf. Öffnen Sie für jeden PHP-vService die Ansicht WAF Mode und vergewissern Sie sich, dass er sich im Blocking mode befindet.

Achtung: Prüfen Sie vor dem Umschalten die für jedes Feld gelernten Signaturausnahmen. Wenn die Ausnahmen für ein Feld den Wert Max. owasp exclusions überschreiten, wird die Signaturprüfung für dieses Feld deaktiviert.

1.2 Zwei benutzerdefinierte Regeln hinzufügen

Fügen Sie in der Ansicht Signature & Rule Library (WAF → Signature & Rule Library → Add) die beiden folgenden Regeln einzeln hinzu. Starten Sie beide im Status Monitor und setzen Sie sie nach Prüfung der Event Logs auf Enabled. Die Regeln gelten für jeden WAF-geschützten vService.

Regel 1: Feld für Session Upload Progress

  • Pattern (Regex): PHP_SESSION_UPLOAD_PROGRESS
  • Inspection Scopes: Form und Raw
  • Score: Very High

Erkennt das Formularfeld, das den Angriffsweg über session upload progress bei CVE-2026-109619 auslöst. Bei Anwendungen, die diese Funktion legitim nutzen, nehmen Sie nur die Upload-Pfade aus, die sie benötigen.

Regel 2: PHPSESSID-Formularfeld

  • Pattern (Regex): ^PHPSESSID$
  • Inspection Scopes: Form
  • Score: Very High

Erkennt Anfragen, die die Session-ID statt in einem Cookie in einem Formularfeld namens PHPSESSID übertragen; einige Angriffswege nutzen diese Form, und in legitimem Traffic kommt sie selten vor. Wenn Ihre Anwendung einen anderen Session-Namen (session.name) verwendet, verwenden Sie diesen Namen.

Damit die Regeln greifen: Die Regeln werden mit den Prüfungen Form und RAW des Seitentyps gescannt, der zur Anfrage passt. Bei einem Seitentyp ohne Form-Prüfung werden Formular- und Datei-Upload-Bodys nicht gescannt.

  • Lassen Sie OWASP check in der Regel Any Paths und in Seitentypen mit eigener Form- oder RAW-Prüfung aktiviert.
  • Fügen Sie jedem glob-Seitentyp mit den Schaltflächen Add common rule for Form und Add common rule for Raw eine eigene Form- und RAW-Prüfung hinzu; verlassen Sie sich nicht auf geerbte Einstellungen.
1.3 Große und nicht prüfbare Bodys blockieren

Nehmen Sie in der Ansicht WAF Rules zwei Einstellungen in der Prüfung RAW vor:

  1. Setzen Sie Raw Body Size auf den größten Body, den der Pfad benötigt (in Byte; zum Beispiel 8388608 = 8 MB auf Pfaden ohne Uploads, 33554432 = 32 MB auf Upload-Pfaden). Der Standardbereich lässt Bodys bis 256 MB zu.
  2. Stellen Sie den Schalter für nicht geparste Bodys von Allow unparsed body auf Block unparsed body um. Andernfalls wird ein Body, der nicht in den Prüfpuffer passt, ohne jegliche Inhaltsprüfung an den Backend Service weitergeleitet.

Wo? Die WAF prüft eine Anfrage nur mit den Einstellungen des Seitentyps, der zu ihrem Pfad passt. Nehmen Sie diese beiden Einstellungen in der Regel Any Paths, in jedem Seitentyp, der in der Spalte Check Fields den Eintrag Raw zeigt, und in jedem glob-Seitentyp vor; fügen Sie einem glob-Seitentyp ohne RAW-Prüfung zuerst mit Add common rule for Raw eine RAW-Prüfung hinzu.

Achtung: Raw Body Size gilt, solange Structure Checks in der Ansicht Checks aktiviert ist. Testen Sie zuerst legitime große Uploads. Bodys, die ohne angegebene Länge gesendet werden, werden von diesem Limit nicht erfasst; auf Pfaden außerhalb der Upload-Pfade können sie mit 2.1 blockiert werden.

Schritt 2: Zusätzliche Maßnahmen

Diese Maßnahmen ergänzen den Basisschutz; wählen Sie diejenigen aus, die zu Ihrer Anwendung passen.

2.1 Datei-Uploads dort blockieren, wo Sie sie nicht benötigen

Angriffsanfragen sind überwiegend Anfragen vom Typ multipart/form-data (Datei-Upload). Wenn in Ihrer Anwendung nur wenige Pfade Dateien annehmen, blockieren Sie Multipart-Anfragen an alle anderen Pfade mit einer Load-Balancer-Regel. Die Regel besteht aus zwei Bedingungen und einer Block-Aktion. Alle Ansichten erreichen Sie über das Configuration Menu, das Sie über das TR7-Logo unten links öffnen.

A. Bedingungen erstellen (Load Balancer → Conditions → Add)

  1. Bedingung für Multipart-Anfragen: Criteria = HTTP header, Abgleichmethode Includes, Header Name = Request → Content-Type, Query = multipart/form-data, Case Insensitive aktiviert. Geben Sie einen Condition Name wie multipart-request ein und speichern Sie mit Add.
  2. Bedingung für Upload-Pfade: Criteria = Path, Abgleichmethode Regex; geben Sie in Query die Pfade ein, die Dateien annehmen (zum Beispiel ^/(upload|media/upload)). Geben Sie einen Condition Name wie upload-paths ein und speichern Sie mit Add.

B. Block-Aktion erstellen (Load Balancer → Actions → Add)

  1. Geben Sie einen Action Name ein (zum Beispiel block-multipart), Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 403.
  2. Wählen Sie unter Conditions multipart-request und !upload-paths in derselben Bedingungsgruppe aus (Standard and). Jede Bedingung erscheint zweimal in der Liste: als sie selbst und als ihre mit ! beginnende Negation (NOT); !upload-paths bedeutet „keiner der Upload-Pfade“.
  3. Aktivieren Sie Hit Counter, um blockierte Anfragen zu zählen, und speichern Sie mit Add.

C. Aktion zum vService hinzufügen

  1. Wählen Sie unter Load Balancer → Load Balancer vService List den vService aus und klicken Sie auf Edit, wählen Sie die Aktion unter Details im Feld Actions aus und klicken Sie auf Save.

D. Auch Bodys ohne angegebene Länge blockieren

  1. Erstellen Sie eine weitere HTTP header-Bedingung: Abgleichmethode Is present, Header Name = Request → Content-Length, Condition Name zum Beispiel has-length.
  2. Erstellen Sie eine zweite Block-Aktion (On Request, Standard, 403). Wählen Sie unter Conditions die vordefinierte Bedingung If HTTP method is POST, !has-length und !upload-paths in derselben Bedingungsgruppe aus und fügen Sie die Aktion dem Feld Actions des vService hinzu. Die POST-Bedingung ist erforderlich; ohne sie werden auch GET-Anfragen ohne Body blockiert.

Das Größenlimit aus 1.3 erkennt die tatsächliche Größe eines ohne angegebene Länge gesendeten Bodys nicht. Diese Regel deckt auf Pfaden außerhalb der Upload-Pfade sowohl gestreamte (chunked) HTTP/1.1-Uploads als auch HTTP/2-Bodys ohne angegebene Länge ab. Auch POST-Anfragen ohne Body und ohne Content-Length-Header werden von dieser Regel erfasst; testen Sie sie zunächst auf einem nicht produktiven vService.

Überprüfung: Eine Multipart-Anfrage (curl -s -o /dev/null -w '%{http_code}\n' -F 'a=b' https://www.example.com/), eine HTTP/1.1-Chunked-Anfrage (curl -s -o /dev/null -w '%{http_code}\n' --http1.1 -H 'Transfer-Encoding: chunked' -d 'a=b' https://www.example.com/) und eine HTTP/2-Anfrage ohne angegebene Länge (printf 'a=b' | curl -s -o /dev/null -w '%{http_code}\n' --http2 -X POST -T - https://www.example.com/) an einen Pfad außerhalb der Upload-Pfade sollten 403 erhalten, und Anfragen an Ihre Upload-Pfade sollten durchgelassen werden. --http1.1 ist für den HTTP/1.1-Test erforderlich: curl verwendet über https standardmäßig HTTP/2 und sendet Transfer-Encoding nicht über HTTP/2. Der Zähler erscheint auf der Registerkarte Action Hits im vService-Dashboard.

Achtung: Eine Block-Aktion ohne ausgewählte Bedingung gilt für jede Anfrage an den vService. Erfassen Sie alle Upload-Pfade vollständig und testen Sie die Regel zunächst auf einem nicht produktiven vService.

2.2 POST-Anfragen pro Client begrenzen

Diese Regel stoppt keinen gezielten Angriff: Der Exploit kann bereits mit wenigen Anfragen funktionieren. Sie erhöht jedoch den Aufwand für automatisierte Tools, die viele Ziele ausprobieren. Die Regel zählt die POST-Anfragen jeder Client-IP und blockiert die POST-Anfragen eines Clients oberhalb des Schwellenwerts mit 429. Die Sperre wird automatisch aufgehoben, wenn der Zähler unter den Schwellenwert fällt.

A. Zähleraktion erstellen (Load Balancer → Actions → Add)

  1. Geben Sie einen Action Name ein, Action Type = Advanced Traffic Inspection, Fields to Track = Client IP address, Traffic Tag = zum Beispiel post-rate (3-20 Zeichen; Buchstaben, Ziffern, -, _), Tracking Period = 1 Minute.
  2. Wählen Sie unter Conditions die vordefinierte Bedingung If HTTP method is POST aus und speichern Sie mit Add. Dadurch werden nur POST-Anfragen gezählt.

B. Schwellenwertbedingung erstellen (Load Balancer → Conditions → Add)

  1. Criteria = Tracking Condition, Tracked Table = post-rate, Tracking Criteria = HTTP requests und der Schwellenwert über Tracking Operator (zum Beispiel > 100). Speichern Sie mit Add.

C. Block-Aktion erstellen (Load Balancer → Actions → Add)

  1. Action Type = Block, Execution Level = On Request, Deny Type = Standard, Status Code = 429.
  2. Wählen Sie unter Conditions die Schwellenwertbedingung aus Schritt 3 und If HTTP method is POST in derselben Bedingungsgruppe aus (Standard and). Ohne die POST-Bedingung werden auch die GET-Anfragen eines Clients oberhalb des Schwellenwerts blockiert. Speichern Sie mit Add.

D. Aktionen zum vService hinzufügen

  1. Wählen Sie im Edit-Formular des vService unter Details → Actions die Zähleraktion zuerst und die Block-Aktion als zweite aus und klicken Sie auf Save. Aktionen werden in der Reihenfolge der Liste ausgeführt.

Überprüfung: Wählen Sie auf der Registerkarte Logs & Tracking des vService in der Liste Logs Type die Tracking-Tabelle der Zähleraktion aus; die POST-Zähler pro Client werden angezeigt. Legen Sie den Schwellenwert anhand des normalen Traffics Ihrer Anwendung fest: Beobachten Sie in der Tabelle die POSTs pro Minute legitimer Clients (zum Beispiel Systeme, die eine API nutzen, oder Organisationen hinter einer gemeinsamen ausgehenden IP) und setzen Sie den Schwellenwert darüber.

2.3 L7-DDoS-Schutz auf Active setzen

Wenn Bot/DDoS-Schutz in Ihrer Lizenz enthalten ist, begrenzt Source IP Request Protection unter L7 DDoS Protection die Gesamtzahl der Anfragen, die eine einzelne Quelladresse in einem Zeitraum stellen kann. Anders als 2.2 zählt sie alle Anfragen und benötigt keine zusätzliche Regel.

  1. Wählen Sie im Edit-Formular des vService unter Details die Option L7 DDoS & Threat Protection aus und klicken Sie auf Save (falls sie nicht aktiviert ist). Wenn der Schutz aktiviert wird, startet L7 DDoS Protection im Modus Monitor; in diesem Modus werden Limitüberschreitungen nur als Ereignisse aufgezeichnet.
  2. Klicken Sie unter Left Monitor Panel → Bot/DDoS Protected vServices → vService → Bot/DDoS Management auf der Karte L7 DDoS Protection auf den Link Edit.
  3. Setzen Sie DDoS Protection = Active und speichern Sie mit der Schaltfläche Edit.
  4. Klicken Sie auf der Karte auf das Stiftsymbol des Blocks Source IP Request Protection. Legen Sie Time Window (Standard 10 Sekunden), Request Limit (Standard 1000) und Limit Action (Standard Show Captcha; Block kann ebenfalls ausgewählt werden) passend zum Traffic Ihrer Anwendung fest und speichern Sie mit der Schaltfläche Edit.

Achtung: Beobachten Sie die Ereignisse eine Zeit lang im Monitor-Modus, bevor Sie auf Active umschalten. Wiederholen Sie dieselbe Beobachtung, wenn Sie das Request Limit senken.

Prüfen, ob Sie ins Visier genommen wurden

Siehe Erkennung und Überwachung. Ausnutzungsversuche wurden bereits vor der öffentlichen Bekanntgabe gemeldet; prüfen Sie daher die Logs ab dem 17. Oktober 2026.

Was eine WAF kann und was nicht

Eine WAF kannEine WAF kann nicht
Bekannte Anfragemuster blockieren, etwa das Feld für Session Upload ProgressDen verwundbaren Code in PHP beheben
Body-Größe, Upload-Pfade und Anfrageraten begrenzenDen Speicherverbrauch innerhalb des PHP-Prozesses messen
Uploads auf Pfaden blockieren, die sie nicht benötigenAnfragen sehen, die Ihren Server erreichen, ohne sie zu passieren
Blockierte und ratenbegrenzte Anfragen aufzeichnenCode rückgängig machen, der bereits auf dem Server ausgeführt wurde

WAF-Regeln verschaffen Zeit für das Update; die dauerhafte Behebung ist ein Update von PHP. Damit diese Schutzmaßnahmen wirken, muss der gesamte Traffic zu Ihren PHP-Anwendungen über TR7 WAF-WAAP laufen.

Erkennung und Überwachung

In TR7

  • Filtern Sie in der Ansicht Event Logs jedes WAF-geschützten vService die Einträge nach Ihren benutzerdefinierten Regeln und prüfen Sie das übereinstimmende Feld und den Score.
  • Prüfen Sie in derselben Ansicht die Anfragen, die durch die Regeln für Body-Größe und nicht geparste Bodys blockiert wurden.
  • Wenn Sie die zusätzlichen Maßnahmen angewendet haben, beobachten Sie die Zähler der Load-Balancer-Regeln auf der Registerkarte Action Hits im vService-Dashboard sowie die Clients, die das POST-Ratenlimit erreichen, in der Tracking-Tabelle auf der Registerkarte Logs & Tracking.

Auf Ihren Servern

  • Durchsuchen Sie die PHP-Fehlerlogs nach Fehlern wie Allowed memory size ... exhausted, Worker-Abstürzen und wiederholten HTTP-500-Antworten; achten Sie besonders auf solche, die unmittelbar auf große Anfragen vom Typ multipart/form-data folgen.
  • Prüfen Sie Antworten auf ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies.
  • Prüfen Sie Web-Root-Verzeichnisse auf neue oder geänderte Dateien und achten Sie auf unerwartete Prozesse, die vom Webserver-Benutzer gestartet wurden, neue Cron-Jobs und unerwartete ausgehende Verbindungen.

Häufig gestellte Fragen

Nein. TR7-Appliances enthalten keine PHP-Komponente, die HTTP-Anfragen verarbeitet, daher sind TR7-Produkte von diesen Schwachstellen nicht betroffen. Siehe „Ist TR7 betroffen?“.

Keine WAF kann vollständig vor diesen Schwachstellen schützen. TR7 WAF-WAAP verkleinert die Angriffsfläche und blockiert bekannte Angriffswege; die einzige vollständige Behebung ist ein Update von PHP.

Verwenden Sie gegen PHP2Shell die beiden benutzerdefinierten Regeln aus TR7 WAF-WAAP 1.2; sie gelten sofort für alle WAF-geschützten vServices.

Nein. Die Schwachstellen liegen in der PHP-Laufzeitumgebung. Aktualisieren Sie PHP selbst oder bitten Sie Ihren Hosting-Anbieter darum.

Ja, das ist möglich. Größenlimits für Request-Bodys, das Blockieren von Uploads und die benutzerdefinierten Regeln können legitime Uploads und Formulare beeinträchtigen. Beginnen Sie bei WAF-Regeln im Monitor mode, prüfen Sie die Event Logs und wechseln Sie dann in den Blocking mode. Testen Sie Load-Balancer-Regeln (2.1, 2.2) zunächst auf einem nicht produktiven vService.

Änderungsverlauf

  • 23. Oktober 2026 Erstveröffentlichung.

Referenzen

Benötigen Sie Hilfe bei der Umsetzung dieser Einstellungen?

Das TR7-Support-Team kann Ihre WAF-Konfiguration prüfen und Sie bei der Einführung dieser Schutzmaßnahmen unterstützen. Wenden Sie sich an Ihren TR7-Ansprechpartner oder an das TR7-Support-Team unter support@tr7.com.

TR7 WAF-WAAP entdecken TR7 kontaktieren Notfall-Support