Kurz gesagt: Viele PHP2Shell-Tipps, die gerade in Foren und sozialen Netzwerken kursieren, schützen nicht oder schaden sogar: Anfragen mit Session-Cookie blockieren, Fehlermeldungen verstecken, Einstellungen per .user.ini setzen oder nur das CMS aktualisieren. php.net ist eindeutig: Es gibt keine vollständigen Übergangsmaßnahmen, das PHP-Update mit Neustart aller Prozesse ist der einzig sichere Weg.
Warum Falschtipps in dieser Lage gefährlich sind
Bei einer kritischen Lücke mit großer Aufmerksamkeit entsteht ein Markt für schnelle Lösungen. Ratschläge werden geteilt, verkürzt und weitergegeben, oft ohne die Einschränkungen der ursprünglichen Quelle. Bei PHP2Shell kommt hinzu, dass Details laut Berichten schon vor dem offiziellen Termin bekannt wurden und die Lage in den ersten Tagen unübersichtlich war.
Ein falscher Tipp schadet doppelt. Er lässt die Lücke offen und erzeugt das Gefühl, etwas getan zu haben. Genau dieses Gefühl führt dazu, dass das eigentliche Update liegen bleibt. Manche Ratschläge legen zusätzlich die eigene Website lahm.
Neun Ratschläge im Faktencheck
Die folgende Tabelle fasst zusammen, was wir in den letzten Tagen häufig gelesen haben, und stellt die Aussagen der Primärquellen dagegen.
| Kursierender Tipp | Warum er nicht trägt | Was stattdessen gilt |
|---|---|---|
Alle Anfragen mit PHPSESSID blockieren |
Von Fachautoren ausdrücklich abgelehnt; legt Logins und Warenkörbe lahm | PHP aktualisieren |
session.upload_progress.enabled=0 reicht |
Schließt laut Fachberichten nicht beide Lücken | Sinnvolle Übergangsmaßnahme, Update bleibt Pflicht |
Werte per ini_set() oder .user.ini setzen |
php.net rät ausdrücklich davon ab | Serverseitig in php.ini, FPM-Pool oder Serverkonfiguration |
| Fehlermeldungen verstecken | Laut php.net helfen error_reporting, display_errors oder @ nicht |
Update; Fehlerausgabe trotzdem nicht öffentlich zeigen |
Speicher über RLIMIT_AS oder RLIMIT_DATA begrenzen |
php.net warnt, dass gerade das die verwundbare Situation auslösen kann | Grenze über Container oder cgroup |
| WordPress oder Plugins aktualisieren | Die Lücke liegt im PHP-Interpreter, nicht im CMS | PHP-Laufzeit aktualisieren |
| Cloudflare oder eine andere WAF genügt | Schutz nur für Verkehr über den Dienst; direkt erreichbare Server bleiben offen | WAF als zusätzliche Schicht, nicht als Ersatz |
| Dienst neu laden statt neu starten | Laut Red Hat genügt ein Reload nicht, bestehende Worker können den alten Zustand behalten | Alle Worker vollständig neu starten |
| Gepatcht heißt sauber | Ein Patch entfernt keine vorher eingeschleuste Schadsoftware | Logs ab 20.10. sichern und auf Spuren prüfen |
Die drei häufigsten Irrtümer genauer erklärt
Das Cookie-Verbot
Der Tipp, alle Anfragen mit dem Session-Cookie PHPSESSID abzuweisen, klingt technisch und entschlossen. Fachautoren lehnen ihn ausdrücklich ab. In der Praxis bricht er alles, was eine Sitzung braucht: Kundenkonten, Warenkörbe, Admin-Bereiche, Formulare mit Schutz gegen Fälschung. Ein Schutz gegen die Lücke ist er nicht.
Die eine Einstellung, die alles löst
session.upload_progress.enabled=0 steht in den Empfehlungen von php.net und ist gegen CVE-2026-115560 die genannte Abhilfe. Daraus wurde in manchen Beiträgen „PHP2Shell abgeschaltet“. Laut Fachberichten schließt diese Einstellung allein aber nicht beide Lücken. Auch memory_limit=-1 beseitigt laut php.net nur den steuerbaren Auslöser; ein Speicherfehler auf tieferer Ebene kann den verwundbaren Pfad weiterhin erreichen. Auf PHP 8.5 blockiert fatal_error_backtraces=0 laut php.net nur den bestätigten Weg über Backtraces.
Wie Sie die Einstellung trotzdem richtig und dauerhaft setzen, beschreibt der Beitrag session.upload_progress abschalten. Die vollständige Liste der Übergangsmaßnahmen steht unter Sofortmaßnahmen ohne Patch.
Der Schutzschild davor
Cloudflare hat laut eigenen Angaben seit dem 21. Oktober Schutzregeln aktiv, auch für Kunden im kostenlosen Tarif. Cloudflare selbst weist aber auf Grenzen hin: Der Schutz greift nur für Verkehr, der über Cloudflare läuft. Ist der Ursprungsserver direkt erreichbar, wird er umgangen. Außerdem prüft Cloudflare zusätzlich die Serverantwort, weil die Anfrage allein nicht immer genügt. Warum eine WAF das Update nicht ersetzt, erklärt der Beitrag WAF oder Update.
Ein Tipp mit Risiko: Upload-Anfragen am Rand filtern
Nicht jeder unbequeme Ratschlag ist falsch. Fachautoren schlagen als vorübergehende, inoffizielle Maßnahme vor, multipart/form-data-Anfragen außerhalb echter Upload-Pfade am Proxy oder in der WAF zu blockieren. Das kann die Angriffsfläche verkleinern, bricht aber Formulare und Uploads, wenn die Liste der erlaubten Pfade unvollständig ist.
Wer diesen Weg geht, sollte ihn vorher in einer Testumgebung prüfen, mit den Fachabteilungen abstimmen und als befristete Maßnahme dokumentieren. Ein Ersatz für das Update ist auch er nicht.
Viele WAF-Lösungen bieten dafür einen Beobachtungsmodus, in dem Regeln zunächst nur protokollieren statt zu blockieren. Lassen Sie eine neue Regel einige Tage so laufen und werten Sie aus, welche legitimen Anfragen betroffen wären. Erst danach schalten Sie auf Blockieren um. So vermeiden Sie, dass Bewerbungsformulare, Kundenportale oder Bildupload im Shop unbemerkt ausfallen.
So prüfen Sie einen Tipp, bevor Sie ihn umsetzen
Vier Fragen trennen brauchbare von gefährlichen Ratschlägen:
- Quelle: Stammt die Empfehlung von php.net, Ihrer Distribution, dem BSI oder einem namentlich genannten Fachautor?
- Anspruch: Wird die Maßnahme als Übergang beschrieben oder als Lösung? Bei PHP2Shell ist nur das Update eine Lösung.
- Nebenwirkung: Was bricht, wenn die Maßnahme greift? Ein Tipp ohne Hinweis auf Nebenwirkungen ist unvollständig.
- Umsetzungsort: Wird die Einstellung serverseitig und nicht überschreibbar gesetzt, gefolgt von einem Neustart aller Worker?
Halten Sie fest, welche Übergangsmaßnahmen Sie wann gesetzt haben. So können Sie sie später gezielt prüfen und erkennen, ob ein vermeintlicher Schutz das eigentliche Update verzögert hat.
Wie hilft PHP SOS konkret?
- Wir prüfen die Maßnahmen, die bei Ihnen bereits umgesetzt wurden, und trennen wirksame von wirkungslosen.
- Wir spielen das PHP-Update ein, starten alle Prozesse neu und belegen den Stand.
- Wo ein Update noch nicht möglich ist, setzen wir Übergangsmaßnahmen nach php.net serverseitig und dokumentiert.
- Mit WAF und virtuellem Patching ergänzen wir den Schutz am Rand, ohne das Update zu ersetzen.
Häufige Fragen
Schützt es, Anfragen mit PHPSESSID zu blockieren?
Nein. Fachautoren lehnen diesen kursierenden Tipp ausdrücklich ab. Er legt Anmeldungen, Warenkörbe und Formulare lahm, ohne die Lücke im Interpreter zu schließen.
Reicht session.upload_progress.enabled=0 gegen PHP2Shell?
Nein. Die Einstellung ist eine von mehreren Übergangsmaßnahmen und schließt laut Fachberichten nicht beide Lücken. Sie ist sinnvoll, ersetzt aber das PHP-Update nicht.
Hilft es, display_errors abzuschalten?
Für PHP2Shell nicht. php.net weist darauf hin, dass das Verbergen von Diagnosen über error_reporting, display_errors oder den @-Operator nicht hilft. In der Produktion sollte display_errors aus anderen Gründen trotzdem aus sein.
Woran erkenne ich einen seriösen Tipp?
Ein seriöser Tipp nennt seine Quelle, beschreibt Grenzen und bezeichnet Übergangsmaßnahmen als solche. Wer verspricht, eine einzelne Einstellung mache das Update überflüssig, liegt bei PHP2Shell falsch.