Kurz gesagt: Ein Workaround für die PHP-Sicherheitslücke PHP2Shell kann das Risiko senken, ersetzt aber das Update nicht. php.net nennt dafür feste Speicher- und Upload-Grenzen, das Abschalten von Session-Upload-Progress und auf PHP 8.5 fatal_error_backtraces=0. Ist auch das nicht kurzfristig möglich, empfiehlt das BSI, den Webserver vorübergehend vom Netz zu nehmen.
Was ein Workaround leisten kann und was nicht
Die Übergangsmassnahmen von php.net sollen die Bedingungen erschweren, unter denen die Lücken CVE-2026-109618 und CVE-2026-109619 ausnutzbar sind. Sie sind ausdrücklich kein vollständiger Schutz. Behoben sind die Lücken nur in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder in einem bestätigten Backport Ihres Anbieters.
Sinnvoll sind die Massnahmen, wenn das Update aus einem konkreten Grund noch nicht geht: ein Wartungsfenster steht noch aus, eine Anwendung muss erst getestet werden, oder Sie betreiben PHP 8.1 oder älter, für das es kein offizielles Update mehr gibt. Sie sind dann eine Brücke, kein Ziel.
Planen Sie deshalb mit dem Workaround zugleich das Update: Wer setzt es um, in welchem Wartungsfenster, und wer prüft danach, dass alle Worker neu gestartet sind? Ein Übergang ohne Enddatum droht zum Dauerzustand zu werden.
Option 1: Server vorübergehend vom Netz nehmen
Das BSI hat Warnstufe 3 (Orange) ausgerufen und empfiehlt, betroffene Webserver vorübergehend vom Netz zu nehmen, wenn das Update nicht sofort möglich ist. Einige Anbieter haben das vorsorglich getan; das bedeutet nicht, dass diese Seiten gehackt wurden.
Für viele Unternehmen ist ein Ausfall des Shops oder Portals teuer. Eine Abwägung kann sinnvoll sein: Zugang nur noch über VPN oder freigegebene IP-Adressen, eine statische Wartungsseite statt der PHP-Anwendung oder das Abschalten einzelner, nicht benötigter Websites auf dem Server. Je weniger PHP von aussen erreichbar ist, desto kleiner die Angriffsfläche.
Wichtig ist, die Entscheidung bewusst zu treffen und festzuhalten: Wer hat wann entschieden, den Server online zu lassen, und mit welchen Schutzmassnahmen? Das hilft später gegenüber Versicherer, Datenschutz und Geschäftsführung.
Die Übergangsmassnahmen von php.net
| Massnahme | Wert | Hinweis |
|---|---|---|
memory_limit |
-1, nicht überschreibbar |
Speichergrenze dann über Container oder cgroup setzen |
post_max_size |
8M ohne Uploads, 32M mit Uploads |
upload_max_filesize darunter |
| Speichergrenze | über Container/cgroup | nicht über RLIMIT_AS oder RLIMIT_DATA |
session.upload_progress.enabled |
0 |
in php.ini, Pool oder Serverkonfiguration, nicht per ini_set() oder .user.ini |
fatal_error_backtraces |
0 |
nur PHP 8.5 |
Die Einstellung session.upload_progress.enabled=0 ist zugleich die Abhilfe für die am 23. Oktober gemeldete Lücke CVE-2026-115560.
Workaround für die PHP-Sicherheitslücke richtig setzen
Entscheidend ist der Ort. Die Werte müssen so gesetzt sein, dass eine Anwendung sie nicht überschreiben kann. Pfade und Dienstnamen weichen je Distribution ab; die Beispiele gehen von PHP 8.3 aus.
PHP-FPM, im Pool (z. B. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache mit mod_php, in der Serverkonfiguration oder im VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Speichergrenze über cgroup, hier per systemd für den FPM-Dienst. Den Wert passen Sie an Ihren Server an:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Danach alle Worker neu starten, sonst greift nichts davon: systemctl restart php8.3-fpm oder bei mod_php Apache. Wie Sie prüfen, dass kein alter Prozess mehr läuft, steht unter PHP-FPM und alle Worker neu starten. Allgemeine Härtung der Konfiguration beschreibt php.ini sicher konfigurieren.
Testen Sie Uploads und grosse Formulare nach der Umstellung. Ein zu knappes post_max_size kann Bestellungen, Bewerbungsformulare oder Medienuploads blockieren. Das ist ein Grund, das Update nicht lange hinauszuschieben.
Zusätzliche Schutzschichten
Eine Web Application Firewall oder virtuelles Patching kann als weitere Schicht helfen. Cloudflare hat Schutzregeln ausgerollt, warnt aber selbst, dass Regeln anhand der Anfragedaten allein nicht genügen. Eine WAF ist deshalb Ergänzung, nicht Ersatz. Mehr dazu unter WAF und virtuelles Patching.
Sichern Sie ausserdem die Server-Logs ab dem 20. Oktober. Laut Medienberichten wurde ein erster Angriffsversuch bereits am 17. Oktober beobachtet; die Logs sind die Grundlage, falls Sie später klären müssen, ob vor dem Patch etwas passiert ist.
Wie hilft PHP SOS konkret?
- Lage klären: Wir prüfen, ob ein Update kurzfristig möglich ist oder ob ein Übergang nötig ist, und besprechen mit Ihnen die Option, Teile vom Netz zu nehmen.
- Massnahmen setzen: Wir tragen die Werte von php.net an der richtigen Stelle ein, setzen die cgroup-Grenze und starten alle Worker neu.
- Funktion testen: Formulare, Uploads und Bestellprozesse prüfen wir nach der Umstellung.
- Zum Patch führen: Über den PHP-Patch-Service planen wir das Update und nehmen die Übergangswerte danach kontrolliert zurück, wo sie stören.
Häufige Fragen
Schützt der Workaround vollständig vor PHP2Shell?
Nein. php.net bezeichnet die Massnahmen ausdrücklich als Übergang und nicht als vollständigen Schutz. Sie verringern das Risiko, bis das Update eingespielt ist. Das BSI empfiehlt, Server ohne Patch vorübergehend vom Netz zu nehmen.
Kann ich die Einstellungen per .htaccess oder .user.ini setzen?
Für session.upload_progress.enabled schliesst php.net ini_set() und .user.ini ausdrücklich aus. Auch für memory_limit gilt: Der Wert muss so gesetzt sein, dass die Anwendung ihn nicht überschreiben kann. Das gelingt in der php.ini, im FPM-Pool mit php_admin_value oder in der Apache-Serverkonfiguration.
Reicht eine Web Application Firewall als Workaround?
Als zusätzliche Schicht kann sie helfen. Cloudflare hat Schutzregeln ausgerollt, weist aber selbst darauf hin, dass Regeln anhand der Anfragedaten allein nicht genügen. Eine WAF ersetzt weder das Update noch die Übergangsmassnahmen auf dem Server.
Was mache ich, wenn ich nur Shared Hosting habe?
Dann liegen php.ini und Neustart beim Hoster. Fragen Sie konkret nach, ob das Update eingespielt oder die Übergangsmassnahmen gesetzt wurden und ob alle PHP-Prozesse neu gestartet sind.