# Sofortmaßnahmen, wenn Sie noch nicht patchen können

> Workaround für die PHP-Sicherheitslücke PHP2Shell: die Übergangsmaßnahmen von php.net, richtig gesetzt, mit Grenzen und Hinweisen für den Weg zum Patch.

Quelle: https://phpsos.de/php2shell/sofortmassnahmen-ohne-patch/  
Stand: 25.10.2026  
Anbieter: PHP SOS, PHP-Notfallhilfe und Server-Sicherheit. Soforthilfe per WhatsApp: https://wa.me/491736494914?text=Hallo%20PHP%20SOS%2C%20wir%20brauchen%20Hilfe%20mit%20unserem%20PHP-Server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**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 Übergangsmaßnahmen 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 Maßnahmen, 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 außen 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 Schutzmaßnahmen? Das hilft später gegenüber Versicherer, Datenschutz und Geschäftsführung.

## Die Übergangsmaßnahmen von php.net

| Maßnahme | 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](https://phpsos.de/php2shell/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`):

```ini
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:

```apache
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:

```ini
# 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](https://phpsos.de/php2shell/php-fpm-neustart/). Allgemeine Härtung der Konfiguration beschreibt [php.ini sicher konfigurieren](https://phpsos.de/ratgeber/php-ini-sicher-konfigurieren/).

> **Wichtig:**
> Testen Sie Uploads und große 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](https://phpsos.de/leistungen/waf-virtuelles-patching/).

Sichern Sie außerdem 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.
- **Maßnahmen 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](https://phpsos.de/leistungen/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 Maßnahmen 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 schließt 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 Übergangsmaßnahmen 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 Übergangsmaßnahmen gesetzt wurden und ob alle PHP-Prozesse neu gestartet sind.

## Quellen

- [php.net: Sicherheitsmeldungen](https://www.php.net/)
- [BSI: Bundesamt für Sicherheit in der Informationstechnik](https://www.bsi.bund.de/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)