Zu den PHP2Shell-Lücken (CVE-2026-109618 und CVE-2026-109619) gibt es seit dem 21. Oktober 2026 Fixes in 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Auf vielen Systemen kommen die Pakete aber erst später an, zum Beispiel auf NAS-Geräten wie Synology, wo PHP über das Paketzentrum läuft. Der Blog mariushosting beschreibt für Synology eine Überbrückung über wenige PHP-Einstellungen. Hier ordne ich sie ein und zeige, wie du sie auch auf Plesk und normalen Servern setzt.
Wichtig vorweg: Das ist kein Fix
Laut PHP-Advisory schützt nur das Update vollständig. Einstellungen wie die folgenden verkleinern einzelne Angriffswege. Sie sind ein Pflaster für die Zeit bis zum Paket, kein Ersatz. Sobald dein Hersteller eine gepatchte Version liefert (8.2.35, 8.3.36, 8.4.27 oder neuer), installierst du sie und nimmst die Notlösung nur dann zurück, wenn die Anwendung es braucht.
Die drei Einstellungen
session.upload_progress.enabled = 0: schaltet die Fortschrittsanzeige für Uploads über die Session ab. Dieser Mechanismus verarbeitet Daten schon beim Upload, deshalb ist abschalten die erste Maßnahme.session.use_only_cookies = 1undsession.use_cookies = 1: Session-IDs werden nur über Cookies akzeptiert, nicht über URL oder Formularfelder.session.use_strict_mode = 1: PHP übernimmt keine Session-ID, die es nicht selbst ausgestellt hat.
Nebenwirkung: Anwendungen, die einen Upload-Fortschrittsbalken über PHP-Sessions bauen, zeigen ihn dann nicht mehr an. Der Upload selbst funktioniert weiter.
So setzt du sie
Synology Web Station: Web Station öffnen, links „Skriptsprachen-Einstellungen“, das PHP-Profil wählen, „Bearbeiten“, Reiter „Core“. Dort session.upload_progress.enabled von 1 auf 0 setzen und die drei session.use_*-Werte auf 1. Danach prüfen, dass deine Website wirklich dieses Profil nutzt (Webdienst in der Seitenleiste). Der Quellblog nennt die Wirkung für PHP 8.4, 8.3, 8.2, 8.0 und älter.
Plesk: Domain, „PHP-Einstellungen“, Feld „Zusätzliche Direktiven“:
session.upload_progress.enabled=0
session.use_only_cookies=1
session.use_cookies=1
session.use_strict_mode=1Eigener Server: eine Datei in conf.d der betroffenen PHP-Version anlegen (zum Beispiel 99-php2shell.ini) und PHP-FPM oder Apache neu starten.
Container: die Datei als ini in das Image einbinden (Volume nach /usr/local/etc/php/conf.d/) und den Container neu starten.
Prüfen, ob es wirkt
php -i | grep -E "session.upload_progress.enabled|session.use_(cookies|only_cookies|strict_mode)"Das zeigt nur die CLI-Werte. Für die Website selbst eine kleine Seite mit phpinfo() kurz aufrufen und danach wieder löschen, oder in Plesk die Einstellungen der Domain prüfen. Wichtig: nach der Änderung PHP neu starten.
Weitere Maßnahmen, die genannt werden
Nach dem Bericht von The Hacker News empfiehlt das PHP-Team für CVE-2026-109618 zusätzlich, memory_limit=-1 zu setzen (damit Anwendungen es nicht überschreiben), post_max_size niedrig zu halten und Größenlimits schon am Webserver zu erzwingen. Lies dazu das Advisory und teste, ob deine Anwendungen mit den Werten leben können.
Meine Empfehlung
- Erst prüfen, welche PHP-Version wirklich läuft, und ob es schon einen gepatchten Stand gibt.
- Gibt es keinen: Notlösung setzen, Anwendung testen, Notiz mit Datum machen.
- Regelmäßig im Paketzentrum oder beim Hoster nachsehen und das Update einspielen, sobald es erscheint.
- Wo möglich auf einen Handler mit zeitnahen Updates wechseln, wie ich es in meinem Beitrag zum PHP-Notfall-Update beschrieben habe.
Quelle der Synology-Anleitung: mariushosting.