LONDON (IT BOLTWISE) – Vor dem PHP-Fix gegen die „PHP2Shell“-Sicherheitslücken reicht eine einzelne Konfigurationsänderung nicht aus, sagt eine beteiligte Sicherheitsfirma. Die empfohlene Einstellung session.upload_progress.enabled=0 soll zwar ein Risiko senken, gilt aber ausdrücklich nicht als vollständiger Schutz. Entscheidend bleibt bis zum Release um 14:00 UTC am 21. Oktober: betroffene Systeme schnell patchen und den Zugriff auf exponierte PHP-Instanzen begrenzen. Wer nicht sofort aktualisieren kann, sollte Internet-Zugriffe isolieren und die Angriffsfläche konsequent reduzieren.

Vor dem geplanten PHP-Update um 14:00 UTC am 21. Oktober steht Admins und Security-Teams eine unangenehme Erkenntnis ins Haus: Die beiden als kritisch bewerteten PHP-RCE-Lücken lassen sich nicht vollständig schon vor dem Patch „wegkonfigurieren“. Laut einer Sicherheitsfirma, die die Schwachstellen in der Diskussion maßgeblich begleitet, reicht die eine auf Social Media und in Fachartikeln genannte Einstellung nicht als alleiniger Schutz aus. Gleichzeitig existieren klare Schritte, mit denen sich das Risiko bis zur Installation spürbar reduzieren lässt – vor allem über Zugriffskontrollen, Netzwerksegmentierung und das schnelle Bereitstellen des Fixes im laufenden Betrieb.
Der konkrete Ratschlag, der so oft weitergereicht wurde, betrifft die PHP-Konfiguration: session.upload_progress.enabled=0. Diese Zeile deaktiviert die Funktion „Session Upload Progress“, die standardmäßig aktiv ist und während eines Dateiuploads den Fortschritt erfasst. Hintergrund: Eine Folgeanfrage kann dann nachschlagen, wie weit ein Upload schon gediehen ist. GMO Flatt Security (Tokyo) hatte diese Änderung zunächst am 21. Oktober früh in den Raum gestellt und dabei selbst eingeschränkt, dass man nicht sicher sein könne, ob sie die Lücken vollständig schließt. Am selben Tag korrigierte die Firma jedoch die Erwartungshaltung: Die Einstellung sei keine vollständige Gegenmaßnahme, und Umgehungen seien zu erwarten. Der Kernpunkt ist dabei weniger die konkrete Parameterzeile, sondern die fehlende Verlässlichkeit, die entsteht, wenn die reale Sicherheitswirkung noch nicht abschließend bestätigt ist.
Warum das so ist, erklärt sich aus zwei inhaltlichen Lücken im „Mitigation-Storytelling“. Erstens erwartet die Sicherheitsfirma zwar eine mögliche Umgehungsroute, nennt aber nicht, wie genau ein Angreifer den Schutz durch die deaktivierte Upload-Progress-Funktion überbrückt. Zweitens bleibt umstritten, ob die Schwachstellen tatsächlich in genau diesem Feature verankert sind: PHP selbst habe noch keine Bestätigung geliefert, welche Komponente betroffen ist. Eine unabhängige Code-Analyse argumentiert zudem, dass der in der Diskussion beschriebene konkrete Bug in freigegebenen PHP-Versionen so nicht existiere. Dieses Audit stammt von einem anonymen Konto und wird letztlich von der PHP-Codebasis beziehungsweise dem Projekt selbst geklärt werden müssen. Genau deshalb raten die Beteiligten dazu, die Konfigurationsänderung nicht als „Schild“ zu betrachten, sondern höchstens als risk-reduzierendes Element bis zum Patch.
Was sich daraus für die Praxis ableitet, ist relativ eindeutig. Wenn die Einstellung bereits gesetzt ist, soll sie nicht zwingend rückgängig gemacht werden; aber sie sollte auch nicht als vollständige Absicherung interpretiert werden. PHPs eigene Dokumentation empfiehlt, die Upload-Progress-Funktion dann zu deaktivieren, wenn eine Anwendung keine Upload-Progress-Balken nutzt, weil gespeicherte Dateinamen und Feldnamen nicht validiert werden und PHP-Code enthalten können. In operativer Hinsicht ist zudem wichtig, dass man den Effekt am richtigen Ort prüft: session.upload_progress.enabled ist INI_PERDIR. Das bedeutet, sie kann in php.ini, in.htaccess oder in.user.ini gesetzt sein. In Umgebungen mit CGI und FastCGI wird eine Änderung in.user.ini nicht sofort von allen Prozessen übernommen, da.user.ini standardmäßig nur alle 300 Sekunden neu eingelesen wird; in solchen Setups kann es also fünf Minuten dauern, bis die neue Konfiguration wirklich greift. Unter dem Apache-Modul entscheidet dagegen, ob.htaccess oder die Serverkonfiguration die maßgebliche Quelle ist. Und: Eine Prüfung nur per „php -i“ im Shell-Kontext sagt wenig darüber aus, was der Webserver tatsächlich ausliefert. Entscheidend ist die Abfrage beim Prozess, der Webanfragen bedient – etwa PHP-FPM oder mod_php.
Sobald der Patch um 14:00 UTC verfügbar ist, verschiebt sich der Fokus von „vorläufiger Risikoreduktion“ auf eine saubere, branche-spezifische Aktualisierung. PHP behebt Sicherheitsprobleme nur in den vier unterstützten Zweigen ab 8.2 bis 8.5; wie weit die betroffenen Versionen zurückreichen, sowie welche exakten Fix-Versionen gelten, soll mit dem Release veröffentlicht werden. Bis dahin empfiehlt CERT-EU für Organisationen ohne sofortige Update-Möglichkeit, internetexponierte Anwendungen zumindest zu isolieren, bis die Lücke geschlossen ist. Aus Sicht des Projekts formuliert es die gleiche Richtung noch drastischer: Eine kurze Abschaltung für einen begrenzten Zeitraum kann für viele Umgebungen die sinnvollste Maßnahme sein, ist aber nicht als realistisches Standardgebot für alle gedacht. In der Zwischenzeit funktionieren in der Praxis vor allem Restriktionen auf Reach: Zugriff nur über VPN, nur für freigeschaltete IPs (Allowlisting) oder nur für authentifizierte Sessions am Edge. Ergänzend sollten Administratoren sicherstellen, dass Angreifer nicht direkt an den Origin-Server gelangen können, auch nicht „um die Controls herum“.
Wenn Angriffe trotz Abschirmung erfolgreich wären, entscheidet die verbleibende Angriffsfläche. GMO Flatt empfiehlt deshalb, Datenmenge und Datenumfang zu reduzieren, die einem kompromittierten Server entgehen könnten, die Privilegien zu senken, gespeicherte Credentials – inklusive Cloud-Rollen – zu entfernen oder zu verengen und Logs zu aktivieren, damit Ereignisse nach einem Patch-Rollout nachvollziehbar bleiben. Ein schwacher Stopgap sei dagegen ein Web Application Firewall-Regelwerk: Es kann zwar Verkehr filtern, aber es ersetzt nicht die Korrektur in der Laufzeit. Für ältere PHP-Zweige wie 8.1 sowie 7.x und 5.x gilt außerdem: Diese sind End-of-Life und erhalten keine PHP-Fixes mehr; hier bleibt nur Upgrade, Offline-Phase oder Isolation. Auch Cloud-Anbieter können kurzfristige Schutzregeln ergänzen, aber solche Signaturen sehen nur den Verkehr, der über den jeweiligen Provider läuft, und können Varianten übersehen.
Für Teams, die von der Lücke betroffen sein könnten, kommt es beim Release-Check auf vier Punkte an: Erstens, welche PHP-Versionen als betroffen gelten und welche Fix-Versionen PHP als sicher freigibt. Zweitens, ob PHP bestätigt oder verwirft, dass die zuvor diskutierte Setting-Änderung als Mitigation geeignet ist. Drittens, ob sich in der Session- beziehungsweise Upload-bezogenen Implementierung tatsächlich Code geändert hat – das würde zugleich die Streitfrage zur betroffenen Komponente stärker eingrenzen. Viertens, ob es in den folgenden Tagen neue Hinweise auf Ausnutzung gibt. Die Quelle nennt zum Zeitpunkt der Beschreibung keine gemeldeten Exploits und verweist darauf, dass ein ursprünglich zirkulierendes Proof-of-Concept-Demomaterial nicht zuverlässig zum Erfolg führt. Das ist aber bewusst als Momentaufnahme zu verstehen, nicht als Dauerzustand. Nach dem Update sollten Sie abschließend die Logs prüfen, um mögliche Voraktivitäten vor der Patch-Installation sichtbar zu machen – denn in der Incident-Response zählt jede Minute, die man auf Erkennungs- und Nachweispunkte verwendet.
Unterm Strich ist die Message für die Betriebspraxis: session.upload_progress.enabled=0 kann bis zum Fix helfen, ersetzt aber keine Aktualisierung und auch keine saubere Zugriffsbeschränkung. Genau deshalb lohnt sich jetzt ein „Patch-Operationalisierungssprint“: Update-Prozess vorbereiten, Konfigänderungen vorher verifizieren und Verantwortlichkeiten für einen möglichen Notfall-Restart klären. Der entscheidende Schutz entsteht erst mit dem Laufzeit-Update selbst, aber die Zeit bis dahin lässt sich durch Isolation, Reach-Reduktion und Logging so überbrücken, dass die reale Wahrscheinlichkeit für eine erfolgreiche Ausnutzung sinkt. Und wenn ein anderes System wie WordPress, Laravel oder eine andere Anwendung „ihren PHP-Stack“ nicht automatisch aktualisiert, bleibt die Verantwortung für das PHP-Runtime-Update bei Serverpaket, Hosting-Image oder Container-Deployment.
💳 Amazon-Kreditkarte mit 2.000 Euro Limit bestellen!
🔥 Heutige Hot Deals bei Amazon: Bis zu 80% Rabatte!
🎉 Amazon Haul-Store für absolute Schnäppchenjäger!
- ★ 23-stufiges KI-Go-Training – Für Spieler mit Grundkenntnissen der Regeln – Entwickelt als intelligenter Trainingspartner passt sich die KI Spielern von 18K bis 9D an. Ideal für alle, die die Grundregeln bereits beherrschen und ihr Spiel verbessern möchten.
- IHR EMOTIONALER AI-BEGLEITER: Eiliko ist mehr als nur ein Anhänger, es ist ein charismatischer KI-Freund. Mit einem dynamischen LED-Bildschirm, der eine Vielzahl von animierten Gesichtern und Ausdrucksformen anzeigt, reagiert er auf Ihre Interaktionen mit einzigartiger Persönlichkeit und Charme.
- 【MEHR LEBEN FÜR DEINEN SCHREIBTISCH】 Lerne Eilik kennen – deinen kleinen Roboter-Freund mit Persönlichkeit. Mit liebevollen Animationen, ausdrucksstarken Reaktionen und spielerischen Interaktionen bringt Eilik mehr Freude in deinen Alltag. Ob auf dem Schreibtisch, im Büro oder am Nachttisch – Eilik wird schnell zu einem vertrauten Begleiter für besondere Momente.
- 【XL-Größe für gedeihende Pflanzen】Geben Sie Ihren Pflanzen den Raum, den sie verdienen! Unser verbessertes, großes 13,7 cm großes Design bietet Platz für Pflanzen mit einem Durchmesser von bis zu 8,9 cm und damit deutlich mehr Platz für Wurzelwachstum und Pflanzengesundheit im Vergleich zu kleineren, veralteten Modellen. Die Produktabmessungen betragen 13,6 x 13,6 x 13,2 cm und das Gerät wiegt nur 355 g.
- V28 Update - JETZT MIT NEUEN FUNKTIONEN! Als Reaktion auf das Ladeproblem von Loona haben wir das automatische Aufladen 2.0 verbessert. Diese Optimierung hilft Loona, die Ladewege in verschiedenen Szenarien zu erkennen und anzupassen, um die Erfolgsquote beim automatischen Aufladen zu erhöhen. Mobile Hotspots können sich mit Loona verbinden und überwinden WLAN-Einschränkungen, sodass Sie jederzeit und überall mit Loona interagieren können.
- Die besten Bücher rund um KI & Robotik!

- Die besten KI-News kostenlos per eMail erhalten!
- Zur Startseite von IT BOLTWISE® für aktuelle KI-News!
- IT BOLTWISE® kostenlos auf Patreon unterstützen!
- Aktuelle KI-Jobs auf StepStone finden und bewerben!
- Künstliche Intelligenz: Dem Menschen überlegen – wie KI uns rettet und bedroht | Der Neurowissenschaftler, Psychiater und SPIEGEL-Bestsellerautor von »Digitale Demenz«
Du hast einen wertvollen Beitrag oder Kommentar zum Artikel "PHP2Shell: Was wirklich gegen die PHP-RCE-Lücken vor dem Fix hilft" für unsere Leser?


#Sophos
Es werden alle Kommentare moderiert!
Für eine offene Diskussion behalten wir uns vor, jeden Kommentar zu löschen, der nicht direkt auf das Thema abzielt oder nur den Zweck hat, Leser oder Autoren herabzuwürdigen.
Wir möchten, dass respektvoll miteinander kommuniziert wird, so als ob die Diskussion mit real anwesenden Personen geführt wird. Dies machen wir für den Großteil unserer Leser, der sachlich und konstruktiv über ein Thema sprechen möchte.
Du willst nichts verpassen?
Du möchtest über ähnliche News und Beiträge wie "PHP2Shell: Was wirklich gegen die PHP-RCE-Lücken vor dem Fix hilft" informiert werden? Neben der E-Mail-Benachrichtigung habt ihr auch die Möglichkeit, den Feed dieses Beitrags zu abonnieren. Wer natürlich alles lesen möchte, der sollte den RSS-Hauptfeed oder IT BOLTWISE® bei Google News wie auch bei Bing News abonnieren.
Nutze die Google-Suchmaschine für eine weitere Themenrecherche: »PHP2Shell: Was wirklich gegen die PHP-RCE-Lücken vor dem Fix hilft« bei Google Deutschland suchen, bei Bing oder Google News!