CVE-2026-109618 Workaround: Übergangsmaßnahmen gegen PHP2Shell und ihre Grenzen

Gibt es einen Workaround für CVE-2026-109618 und CVE-2026-109619?

Nur teilweise, und keiner davon ist ein Fix. Der Sicherheitshinweis von PHP sagt sinngemäß: Nur ein Update ist eine vollständige Lösung; die folgenden Maßnahmen verringern die Angriffsfläche für bestimmte Angriffspfade, machen eine Installation aber nicht sicher. Für CVE-2026-109619 ergänzt das GitHub-Advisory, dass es keine vollständige, allgemeine Abhilfe per Konfiguration gibt. Nutzen Sie diese Einstellungen nur, um Zeit zu gewinnen, bis Sie den PHP2Shell-Patch eingespielt haben.

Welche offiziellen Übergangsmaßnahmen gibt es?

Jede dieser Einstellungen greift erst nach einem Neustart aller PHP-Worker. PHP warnt außerdem: Ersetzen Sie das Limit nicht durch RLIMIT_AS oder RLIMIT_DATA, denn diese können genau den verwundbaren Speicherfehler auslösen. Fehler mit error_reporting, display_errors oder @ zu unterdrücken, hilft ebenfalls nicht.

Wie setze ich den Workaround mit session.upload_progress richtig um?

Die Einstellung muss greifen, bevor PHP die Anfrage verarbeitet:

1. Setzen Sie session.upload_progress.enabled=0 in der php.ini, in der Konfiguration des PHP-FPM-Pools oder in der Webserver-Konfiguration.
2. Verwenden Sie dafür kein ini_set() im Code und keine FPM-.user.ini-Datei; beide greifen zu spät.
3. Starten Sie alle PHP-Worker neu (alle PHP-FPM-Pools oder Apache bei mod_php). Worker ohne Neustart laufen mit den alten Einstellungen weiter.

Beim Shared Hosting können Sie diese Einstellungen meist nicht selbst ändern; wenden Sie sich an Ihren Hoster oder lassen Sie den Patch über ihn einspielen.

Ist „meine Website hat keine Upload-Funktion“ ein Workaround?

Nein. Die Angriffspfade liegen in der Anfrageverarbeitung von PHP, nicht im Upload-Formular Ihrer Website. Eine Website ohne Upload-Funktion ist deshalb nicht automatisch sicher. Aus diesem Grund ist die offizielle Einstellung eine PHP-Option auf Serverebene und kein Schalter in der Anwendung.

Zählt eine WAF wie Cloudflare als Workaround?

Nein. Eine WAF ist eine zusätzliche Schutzschicht, kein Fix. Cloudflare hat etwa neun Stunden vor der Veröffentlichung automatisch WAF-Regeln für alle Tarife mit WAF ausgerollt, einschließlich Free, und berichtet, dass Angreifer ihre Payloads verändern, um diese Regeln zu umgehen. Eine WAF filtert nur Verkehr, der durch sie hindurchläuft; das PHP auf Ihrem Server bleibt verwundbar.

Funktioniert ein Wartungsmodus-Plugin als Workaround?

Nicht zuverlässig. Auch eine WordPress-Wartungsseite wird von PHP ausgeliefert, und manche Angriffspfade greifen, bevor Anwendungscode läuft. Wenn Sie ohne Patch nicht mehr angreifbar sein wollen, blockieren Sie Anfragen, bevor sie PHP erreichen, oder nehmen Sie die Website vom Netz. Das haben mehrere nationale Behörden für Websites empfohlen, die sich nicht aktualisieren lassen.

Wie lange kann ich mich auf einen Workaround verlassen?

Nur bis Sie aktualisieren können, idealerweise wenige Tage. Die Fixes und technische Analysen sind öffentlich, und Sansec rechnet mit massenhafter Ausnutzung. Planen Sie das Update jetzt. Prüfen Sie Ihren Stand mit dem PHP2Shell-Checker und lesen Sie die Details zu den beiden Lücken unter CVE-2026-109618 und CVE-2026-109619.

Welche Quellen belegen diese Seite?

• The PHP Group: Sicherheitshinweis mit Übergangsmaßnahmen
• GitHub-Advisory GHSA-w8hw-w9fx-j79w
• GitHub-Advisory GHSA-6wmf-4rv5-p3rp
• Cloudflare: WAF-Schutzmaßnahmen
• Sansec: PHP2Shell-Forschung