PHP2Shell mit LoadMaster WAF mitigieren

Am 20. Oktober 2026 wurden kritische Sicherheitslücken in PHP öffentlich bekannt gegeben. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 wurden „PHP2Shell“ genannt und hatten weitreichende Auswirkungen auf das öffentliche Internet, was die Aktualisierung einer großen Anzahl anfälliger Webserver erforderlich machte.

Innerhalb des ersten Tages nach der Offenlegung meldeten CDN-Dienste eine große Anzahl von Versuchen, diese Schwachstellen in ihren Netzwerken auszunutzen. Glücklicherweise sind die PHP-Schwachstellen zwar schwerwiegend und erfordern eine dringende Behebung, könnten aber in der Praxis schwierig auszunutzen sein. Kurz gesagt, der Kern der Schwachstellen besteht darin, dass speziell gestaltete HTTP-Anfragen außergewöhnliche Bedingungen auf dem Webserver verursachen können (insbesondere einen Out-of-Memory-Zustand, „OOM“). Dies kann durch große HTTP-Anfragen verursacht werden. Eine erfolgreiche Ausnutzung kann zu Remote Code Execution (RCE), Denial of Service (DoS) durch Dienstfehler und der Offenlegung sensibler Daten führen.

Der einzige Weg, diese Probleme vollständig zu beheben und zu lösen, ist die Aktualisierung von PHP auf dem betroffenen Webserver auf eine fehlerbereinigte Version. Dies wurde in den offiziellen PHP-Sicherheitshinweisen (die hier und hier zu finden sind) sowie in der Analyse und Berichterstattung der meisten Sicherheitsforscher und -organisationen bestätigt.

Es ist möglich, nur partielle Kontrollen mithilfe einer Web Application Firewall (WAF) oder eines Reverse Proxys zu implementieren: zwei Kernfunktionen, die Progress® Kemp® LoadMaster® bietet.

In diesem Blogbeitrag besprechen wir eine Reihe von Abhilfemaßnahmen, die sofort mit LoadMaster WAF eingesetzt werden können. Denken Sie daran, dass dies ausschließlich Risikominderungen sind und keinen vollständigen Schutz bieten. Eine anfällige PHP-Installation muss vollständig gepatcht werden, um umfassende Korrekturen zu erhalten.

Blockieren von Multipart-Anfragen mit LoadMaster WAF

Einer der bisher beobachteten Hauptangriffsvektoren ist die Verwendung von HTTP-Multipart-Anfragen. Dies ist der HTTP-Mechanismus, der üblicherweise für Datei-Uploads und manchmal für die Übermittlung von Formulardaten verwendet wird.

Alle Multipart-Anfragen über den LoadMaster WAF ablehnen, um diesen Angriffsvektor vollständig zu unterbinden. Wenn eine Anwendung keine Multipart-Anfragen verwendet, sollte diese Abhilfemaßnahme problemlos sein. Andernfalls können Teile einer Anwendung vorübergehend nicht mehr funktionieren (z. B. Datei-Upload-Funktionen). Dies kann ein akzeptabler Kompromiss sein, bis die vollständige PHP-Patchung durchgeführt werden kann, z. B. während des nächsten Wartungsfensters.

Um diese Maßnahme anzuwenden, kopieren Sie die folgende benutzerdefinierte WAF-Regel in einen Texteditor deiner Wahl und speichern Sie die Datei als „php2shell_block-multipart-requests.conf“:

SecRule REQUEST_HEADERS:Content-Type "@contains multipart" \
    "id:1000,\
    phase:1,\
    deny,\
    t:none,t:lowercase,\
    log,\
    msg:'Anfrage mit Multipart-Content-Type',\
    logdata:'%{MATCHED_VAR}',\
    tag:'php2shell-mitigation',\
    tag:'LoadMaster',\
    tag:'PROGRESS-KEMP',\
    ver:'PROGRESS-KEMP/php2shell/1.0'"

Laden Sie die Datei in Ihren LoadMaster unter Web Application Firewall > Custom Rules, wie unten gezeigt:

Wenden Sie die Mitigationsregel auf Ihren virtuellen Dienst in der Box Regeln verwalten an, wie unten gezeigt:

Testen Sie die Mitigation, indem Sie eine Multipart-Upload-Anfrage senden, wie folgt:

$ curl -v 192.168.2.150 -F file=@cat.jpg
⋮
> POST / HTTP/1.1
> Host: 192.168.2.150
> User-Agent: curl/8.22.0
> Accept: */*
> Content-Length: 2468843
> Content-Type: multipart/form-data; boundary=------------------------be3gVtLXHfEIf6Ki69M5l4
⋮
< HTTP/1.1 403 Forbidden
⋮
<html><head><title>403 Forbidden</title></head><body>Access denied</body>

Überprüfen Sie die abgelehnte Anfrage im WAF-Protokoll auf dem LoadMaster, indem Sie zu System Configuration > Logging Options > System Log Files navigieren und die WAF Event Log File öffnen:

2026-10-23T11:34:02+00:00…[client 192.168.2.1]
ModSecurity: Zugriff verweigert mit Code 403…String-Übereinstimmung "multipart" bei REQUEST_HEADERS:Content-Type…
[msg "Anfrage mit Multipart-Content-Type"]…

1b: Multipart-Anfragen selektiv blockieren

Wenn eine Anwendung Multipart-Anfragen (z. B. Datei-Uploads) an bestimmte Speicherorte erfordert, um zu funktionieren, kann ein differenzierterer Ansatz gewählt werden. Die vorherige Regel kann erweitert werden, um Multipart-Anfragen selektiv zu blockieren. Eine Liste ausgeschlossener URIs wurde hinzugefügt: Multipart-Anfragen sind nur für diese Speicherorte zulässig; für alle anderen Speicherorte werden Multipart-Anfragen standardmäßig weiterhin abgelehnt.

Im folgenden Beispiel wurden die Speicherorte „/uploads“ und „/users/folders/create“ vom Multipart-Anfrageblock ausgeschlossen:

SecRule REQUEST_HEADERS:Content-Type "@contains multipart" \
    "id:1010,\
    phase:1,\
    deny,\
    t:none,t:lowercase,\
    log,\
    msg:'Request with multipart content type',\
    logdata:'%{MATCHED_VAR}',\
    tag:'php2shell-mitigation',\
    tag:'LoadMaster',\
    tag:'PROGRESS-KEMP',\
    ver:'PROGRESS-KEMP/php2shell/1.0',\
    chain"
    SecRule REQUEST_URI "!@rx ^(/uploads|/users/folders/create)$" \
        "t:none"

Mit der neuen benutzerdefinierten Regel funktioniert das Testen an einem ausgeschlossenen Speicherort:

$ curl -v 192.168.2.150/users/folders/create --form file=@cat.jpg
⋮
> POST /users/folders/create HTTP/1.1
⋮
> Content-Length: 2468843
> Content-Type: multipart/form-data; boundary=------------------------QRjVQTpdNC4LF085wFZc0c
⋮
< HTTP/1.1 200 OK

Das Testen an einem anderen Speicherort wird wie erwartet verweigert:

$ curl -v 192.168.2.150/foo --form file=@cat.jpg
⋮
> POST /foo HTTP/1.1
⋮
> Content-Length: 2468843
> Content-Type: multipart/form-data; boundary=------------------------fggh3h7ocaisLUHqfL37LT
>
< HTTP/1.1 403 Forbidden

Die für den Ausschluss spezifischer Speicherorte verwendete reguläre Expression kann bei Bedarf erweitert werden, um beispielsweise dynamische Speicherorte einzuschließen.

Anfragen einschränken

Wenn es nicht möglich ist, Multipart-Anfragen zu blockieren (z. B. weil sie zu tief in eine Anwendung integriert sind, um blockiert zu werden), besteht der nächstbeste Ansatz darin, sie einzuschränken, um das Risiko zu minimieren, dass sie Out-of-Memory (OOM)-Probleme in PHP auf einem Backend-Server verursachen.

Stellen Sie zunächst sicher, dass die Option „HTTP POST Request Bodies prüfen“ auf der Seite „Erweiterte Einstellungen“ unter der Registerkarte „WAF“ für den betreffenden virtuellen Dienst aktiviert ist. Andernfalls funktionieren die folgenden Einschränkungen nicht:

2a: Anzahl der Multipart-Header begrenzen

Um die Größe und Komplexität zulässiger Multipart-Anfragen zu beschränken, können Sie die Anzahl der Multipart-Header begrenzen. Dies sollte einfache Datei-Uploads ermöglichen, aber ungewöhnliche, komplexe Anfragen blockieren, die viele Multipart-Header enthalten. Wenn die hier angegebene Beispielbegrenzung Probleme mit echtem, legitimen Traffic verursacht, kann sie erhöht werden, bis keine Probleme mehr auftreten.

Hier ist eine Beispielregel, um die Anzahl der Multipart-Header auf maximal 4 zu begrenzen:

SecRule &MULTIPART_PART_HEADERS "@gt 4" \
    "id:1100,\
    phase:2,\
    deny,\
    t:none,\
    log,\
    msg:'Zu viele Multipart-Header',\
    logdata:'%{MATCHED_VAR}',\
    tag:'php2shell-mitigation',\
    tag:'LoadMaster',\
    tag:'PROGRESS-KEMP',\
    ver:'PROGRESS-KEMP/php2shell/1.0'"

Testen, ob ein einfacher Datei-Upload wie vorgesehen funktioniert:

$ curl -v 192.168.2.150 --form file=@cat.jpg
⋮
> POST / HTTP/1.1
⋮
< HTTP/1.1 200 OK

Testen, ob eine Multipart-Anfrage, die mehrere Header über mehrere Teile verteilt enthält, wie erwartet abgelehnt wird:

$ curl -v 192.168.2.150 \
--form 'surname=jones;headers="X-New-Hdr: foo";headers="X-Something: bar"' \
--form 'fruit=kiwi;headers="Forwarded: yes"'
⋮
> POST / HTTP/1.1
⋮
> Content-Length: 313
> Content-Type: multipart/form-data; boundary=------------------------1UJd5CDDxmU7AMmvOb8wtJ
⋮
< HTTP/1.1 403 Forbidden

Dies in den LoadMaster WAF-Protokollen überprüfen:

…Zugriff verweigert mit Code 403 (Phase 2). Operator GT matched 4 bei MULTIPART_PART_HEADERS…[msg "Zu viele Multipart-Header"] [data "5"]…

2b: Allgemeine Größe des Anforderungs-Body begrenzen

Es ist ratsam, auch die maximal zulässige Größe von Anforderungs-Bodies zu begrenzen. Dies gilt für Anfragen wie POSTs mit dem Content-Type „x-www-form-urlencoded“, bei denen Client-Daten im Anforderungs-Body in der Form „arg1=foo&arg2=bar&…“ gesendet werden. Dies wird häufig bei einfachen Formularübermittlungen und Anmeldeseiten verwendet, zum Beispiel („username=foo&password=bar“). Solche Anfragen können, genau wie Multipart-Anfragen, auch missbraucht werden, um eine Out-of-Memory-Situation zu verursachen.

Um die maximale Größe des Anforderungs-Bodys zu begrenzen, navigieren Sie zum WAF-Tab des betreffenden virtuellen Dienstes und klicken Sie auf die Schaltfläche Erweiterte Einstellungen in der unteren rechten Ecke. Stellen Sie die Größenbeschränkung des Anforderungs-Bodys auf die maximal zulässige Anzahl von Bytes ein. Ein sinnvoller Wert (hoch genug, um viele Anwendungen nicht zu beeinträchtigen) könnte 512 kB sein, obwohl viele Anwendungen mit deutlich weniger (8 kB oder sogar weniger) auskommen und hier mit einem viel kleineren und sichereren Wert eingestellt werden können.

Klicken Sie auf die Schaltfläche „Set Request Size Limit“, wenn Sie die Einstellung übernehmen möchten:

Die hier konfigurierte Größe muss ausreichen, um den größten Anforderungs-Body aufzunehmen, den die Webanwendung bei legitimer Nutzung benötigt (Datei-Uploads zählen nicht zu diesem Limit und werden separat behandelt). Betrachten wir zum Beispiel eine JSON-API. Wenn die größte Anforderungs-Body-Größe im Normalbetrieb ein 28 kB großer JSON-Blob ist, könnte dieses Limit beispielsweise auf 32 kB festgelegt werden.

Beachten Sie, dass diese Einstellung die maximale Größe von Multipart-Datei-Upload-Anfragen nicht beeinflusst.

Testen

Bereiten Sie zunächst eine Testdatei vor, die unter dem Limit liegt, und eine weitere Datei, die über dem Limit liegt. Eine einfache Möglichkeit, dies auf einem Linux-Computer zu tun:

$ base64 -w0 </dev/urandom | head -c 511000 >511k.b64
$ base64 -w0 </dev/urandom | head -c 513000 >513k.b64

Das Senden der kleineren Datei funktioniert einwandfrei:

$ curl -v 192.168.2.150 --data @511k.b64
⋮
> POST / HTTP/1.1
⋮
> Content-Length: 511000
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 511000 bytes
< HTTP/1.1 200 OK

Das Senden der größeren Datei wird abgelehnt:

$ curl -v 192.168.2.150 --data @513k.b64
⋮
> POST / HTTP/1.1
⋮
> Content-Length: 513000
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 513000 bytes
< HTTP/1.1 413 Unknown error

Mit einem unterstützenden Protokolleintrag im WAF-Protokoll:

Die Länge der Anforderungsdaten ohne Dateien ist größer als das konfigurierte Limit (512000).

Dateigrößen für Uploads begrenzen

Eine separate Begrenzung steuert die maximal zulässige Größe von Multipart-Anfragen für Datei-Uploads. Diese sollte in der Regel größer sein als die allgemeine Begrenzung der Anfragetextgröße (Datei-Uploads sollten normalerweise viel größer sein als generische POST-Anfragen; Datei-Uploads sind über eine WAF wesentlich kostengünstiger zu verarbeiten). Um die Sicherheitskontrollen zur Minderung von PHP2Shell zu verschärfen, sollte diese Begrenzung angemessen niedrig angesetzt werden, um große Anfragen zu vermeiden, die OOM-Fehler in PHP verursachen könnten.

Um die maximale Dateiuploadgröße beispielsweise auf 3 MB festzulegen, verwenden Sie eine benutzerdefinierte Regeldatei wie die folgende und laden sie auf einen LoadMaster hoch:

SecAction "id:2000,phase:1,pass,nolog"
SecRequestBodyLimit 3000000

Dies kann getestet werden, indem eine Datei hochgeladen wird, die kleiner ist als das definierte Limit, und eine, die größer ist:

$ head -c 2MB </dev/urandom >2M.bin
$ head -c 4MB </dev/urandom >4M.bin

Die kleinere Datei wird erfolgreich hochgeladen:

$ curl -v 192.168.2.150 --form file=@2M.bin
⋮
> POST / HTTP/1.1
⋮
> Content-Length: 2000210
> Content-Type: multipart/form-data; boundary=------------------------qQmleTErGq9xhWGMaxC6Rf
> 
* upload completely sent off: 2000210 bytes
< HTTP/1.1 200 OK

Die größere Datei wird wie beabsichtigt blockiert:

$ curl -v 192.168.2.150 --form file=@4M.bin
⋮
> POST / HTTP/1.1
⋮
> Content-Length: 4000210
> Content-Type: multipart/form-data; boundary=------------------------uhx2FpkMMdA2osVLDDwPre
> 
* upload completely sent off: 4000210 bytes
< HTTP/1.1 413 Unknown error

3: Blockieren von Erwähnungen des PHP-Upload-Fortschritts

Der Mechanismus für den Upload-Fortschritt von Sessions in PHP ist ein weiterer bestätigter Angriffsvektor. Einige POST-Anfragen verweisen explizit auf diesen Mechanismus. Das Blockieren dieser Verweise ist nicht als Minderung dieses Angriffsvektors bestätigt: Es ist jedoch eine sehr einfache Methode, um viele der Sonden, Scanner und PoCs, die diese Schwachstelle testen, sofort zu blockieren.

Um die Standardzeichenfolge zum Referenzieren des PHP-Upload-Fortschrittsmechanismus zu blockieren, verwenden Sie eine benutzerdefinierte WAF-Regel wie die folgende:

SecRule ARGS_NAMES|FILES_NAMES "@contains php_session_upload_progress" \
    "id:1200,\
    phase:2,\
    deny,\
    t:none,t:lowercase,\
    log,\
    msg:'Referenz auf den Standard-PHP-Upload-Fortschrittsmechanismus',\
    logdata:'%{MATCHED_VAR}',\
    tag:'php2shell-mitigation',\
    tag:'LoadMaster',\
    tag:'PROGRESS-KEMP',\
    ver:'PROGRESS-KEMP/php2shell/1.0'"

Um diese Regel zu testen, senden Sie eine Anfrage wie die folgende:

$ curl -v 192.168.2.150 --form "PHP_SESSION_UPLOAD_PROGRESS=foo"
⋮
< HTTP/1.1 403 Forbidden

Bestätigt durch eine unterstützende WAF-Protokollzeile wie die folgende:

…Zugriff verweigert mit Code 403 (Phase 2). Zeichenkettenübereinstimmung "php_session_upload_progress" bei ARGS_NAMES:PHP_SESSION_UPLOAD_PROGRESS…[msg "Referenz auf den Standard-PHP-Upload-Fortschrittsmechanismus"] [data "php_session_upload_progress"]…

Schütze alle deine Anwendungen mit LoadMaster WAF

Die hier vorgestellten defensiven Maßnahmen können PHP-Anwendungen mithilfe von LoadMaster WAF vor PHP2Shell-Angriffen schützen. Durch die Flexibilität und die benutzerdefinierte Regellogik von LoadMaster WAF lassen sich schnell und einfach individuelle Abwehrmaßnahmen implementieren, einschließlich Notfallschutzmaßnahmen wie die hier gezeigten.

Es ist wichtig, auf den nächsten Cybersicherheitsnotfall vorbereitet zu sein. Es ist entscheidend, alle Webanwendungen vor Angriffen zu schützen. Jede öffentlich zugängliche Website und Webanwendung sollte durch eine WAF geschützt werden. Mit LoadMaster WAF ist dies ein erreichbares Ziel.

Dank der erweiterten WAF-Funktionalität in LoadMaster 360 ist die Abstimmung und Wartung eines WAF-Setups zu einem automatisierten Prozess geworden, ohne dass Protokolldaten manuell verarbeitet und WAF-Regelausschlüsse von Hand geschrieben werden müssen.

Sehen Sie sich unsere aktuelle und laufende Kurzvideo‑Reihe an: '‘Getting Started with the LoadMaster WAF’'. Diese kurzen, leicht verdaulichen Videos vermitteln die wichtigsten Konzepte, um schnell mit der Bereitstellung und Einrichtung der WAF zu beginnen.

Bitte kontaktieren Sie uns bei Fragen: Lassen Sie uns Ihre spezifischen Anwendungsfälle besprechen und Sie dabei unterstützen, Ihre APIs, Webanwendungen und KI-gestützten Systeme robust zu schützen.

Abschließend laden wir Sie ein, unsere voll ausgestattete 30-tägige kostenlose Testversion auszuprobieren: Testen Sie sie, probieren Sie einige der oben genannten Schutzmaßnahmen aus und prüfen Sie, ob sie Ihren Anforderungen entspricht.