Kurz gesagt: Virtuelles Patching für PHP überbrückt die Zeit, bis das echte Update eingespielt ist. Wir kombinieren dafür Regeln einer Web Application Firewall mit den Übergangsmaßnahmen, die php.net zu PHP2Shell veröffentlicht hat, und legen gleich den Weg zum regulären Patch fest. Vollständigen Schutz bietet das nicht, es verringert aber das Risiko in der Übergangszeit.
Wann virtuelles Patching für PHP sinnvoll ist
Das BSI empfiehlt bei PHP2Shell das sofortige Update und, wenn das nicht geht, die Webserver vorübergehend vom Netz zu nehmen. Für viele Unternehmen ist beides nicht sofort machbar: Ein Shop muss erreichbar bleiben, eine Eigenentwicklung braucht vor dem Update einen Test, oder der Server läuft mit PHP 8.1 und älter, für das es keine offiziellen Updates mehr gibt.
In diesen Fällen ist virtuelles Patching eine Brücke. Es ersetzt nicht die Entscheidung, ob ein Offline-Betrieb angemessener wäre. Diese Abwägung treffen Sie, wir liefern die technische Einschätzung.
Warum eine WAF allein nicht reicht
Cloudflare meldete beobachtete Angriffsversuche und hat Schutzregeln ausgerollt, warnt aber, dass Regeln anhand der Anfragedaten allein nicht genügen. Der Grund liegt in der Art der Lücken. Bei CVE-2026-109618 kann ein Out-of-Memory-Zustand PHP unterbrechen, während Anfragedaten nur teilweise initialisiert sind. Bei CVE-2026-109619 kann interner Zustand nach dem Freigeben des Speichers bestehen bleiben und von einer späteren Anfrage im selben Worker genutzt werden. Solche Fehler hängen vom Zustand des Servers ab, nicht nur vom Inhalt einer einzelnen Anfrage.
Deshalb setzen wir auf mehrere Schichten: WAF-Regeln vor dem Server, Übergangsmaßnahmen in PHP selbst und eine verstärkte Beobachtung des Servers. Jede Schicht fängt einen Teil ab, keine allein reicht. Zusammen verschaffen sie Ihnen die Zeit, das Update geordnet einzuspielen.
Die Übergangsmaßnahmen laut php.net
php.net nennt mehrere Einstellungen, die das Risiko senken, ausdrücklich ohne vollständigen Schutz. Wichtig ist, dass Anwendungen diese Werte nicht überschreiben können. Ein Beispiel für einen PHP-FPM-Pool mit Uploads:
; Übergangsmaßnahmen PHP2Shell (kein vollständiger Schutz), danach alle Worker neu starten
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; nur PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Ohne Uploads empfiehlt php.net post_max_size = 8M. Weil memory_limit aufgehoben wird, gehört eine Speichergrenze auf Ebene von Container oder cgroup dazu, nicht über RLIMIT_AS oder RLIMIT_DATA. Die Einstellung session.upload_progress.enabled=0 gehört in php.ini, FPM-Pool oder Serverkonfiguration, nicht in ini_set() oder .user.ini. Sie ist zugleich die Abhilfe für den Hinweis zu CVE-2026-115560. Alle Maßnahmen im Überblick stehen unter Sofortmaßnahmen, wenn Sie noch nicht patchen können.
Übergangsmaßnahmen wirken erst nach einem Neustart aller PHP-Worker. Und sie schützen nur vor künftigen Angriffen: Ob vorher schon jemand eingedrungen ist, beantworten sie nicht.
Wann der Offline-Betrieb die bessere Wahl ist
Virtuelles Patching ist nicht in jeder Lage die richtige Antwort. Bei manchen Konstellationen raten wir, dem BSI zu folgen und den Webserver vorübergehend vom Netz zu nehmen, bis gepatcht ist:
- der Server läuft mit Apache und mod_php, wo das PHP-Team das Risiko am höchsten einstuft und ein Exploit gezeigt wurde, bevor überhaupt Anwendungscode läuft
- auf dem Server liegen besonders schützenswerte Daten, etwa Gesundheits-, Mandanten- oder Zahlungsdaten
- es gibt keine Möglichkeit, die Übergangsmaßnahmen fest in der Serverkonfiguration zu setzen, etwa bei bestimmten Shared-Hosting-Paketen
- es bestehen bereits Anzeichen, dass der Server angegriffen wurde
Ein vorübergehender Offline-Betrieb bedeutet nicht, dass Ihre Website gehackt wurde. Einige Anbieter haben Websites aus Vorsicht offline genommen. Eine kurze, sachliche Hinweisseite für Besucher ist dann meist die bessere Lösung als ein unerklärter Ausfall.
Wie hilft PHP SOS konkret?
- Lage prüfen: Wir erfassen PHP-Versionen, Betriebsarten und bestehende Schutzschichten wie CDN, WAF oder Reverse Proxy. Bei mod_php weisen wir auf das erhöhte Risiko hin, das das PHP-Team dort sieht.
- Schichten aufbauen: Wir aktivieren oder ergänzen WAF-Regeln, setzen die Übergangsmaßnahmen fest in der Serverkonfiguration und begrenzen den Speicher über Container oder cgroup. Für Nginx-Setups orientieren wir uns an Nginx mit PHP-FPM absichern.
- Neustart und Test: Alle PHP-Prozesse werden neu gestartet, danach prüfen wir Uploads, Formulare, Login und Kasse.
- Beobachten: In der Übergangszeit achten wir verstärkt auf Abstürze von Workern, Speicherspitzen und ungewöhnliche Prozesse.
- Patch planen: Wir legen fest, wann und wie das reguläre Update kommt, und setzen es über den PHP-Patch-Service um.
Was Sie bekommen, was wir brauchen und was wir nicht versprechen
Sie bekommen eine Dokumentation aller gesetzten Regeln und Einstellungen mit Begründung, die Testergebnisse und einen Termin- und Maßnahmenplan für den echten Patch. Von Ihnen brauchen wir Server- oder Panelzugang, Zugang zu CDN oder WAF, falls vorhanden, einen technischen Ansprechpartner und Angaben zu Upload-Funktionen Ihrer Anwendungen.
Wir versprechen nicht, dass virtuelles Patching einen Angriff verhindert. Es senkt das Risiko für eine begrenzte Zeit. Bei PHP 8.1 und älter ist es kein Dauerzustand; hier gehört die Migration auf eine unterstützte Version auf den Plan.
Häufige Fragen
Was ist virtuelles Patching?
Virtuelles Patching bedeutet, eine bekannte Lücke vor der Anwendung abzuschirmen, statt den Code selbst zu ändern. Das geschieht meist über eine Web Application Firewall oder Konfigurationsänderungen. Es ist eine Überbrückung, kein Ersatz für das Update.
Reicht die WAF meines CDN-Anbieters gegen PHP2Shell?
Allein in der Regel nicht. Cloudflare hat Schutzregeln ausgerollt, warnt aber selbst, dass Regeln anhand der Anfragedaten allein nicht genügen. Die WAF ist eine zusätzliche Schicht neben Übergangsmaßnahmen und Patch.
Wie lange darf ich mich auf virtuelles Patching verlassen?
So kurz wie möglich. Es soll die Zeit bis zum regulären Update überbrücken, etwa bis ein Wartungsfenster frei ist oder eine Anwendung getestet wurde. Bei PHP 8.1 und älter gehört ein Migrationsplan dazu.
Können die Übergangsmaßnahmen meine Website stören?
Ja, das ist möglich. Kleinere Upload-Grenzen können große Dateiuploads verhindern, und das Abschalten von Session-Upload-Progress betrifft Fortschrittsanzeigen beim Hochladen. Wir testen die wichtigsten Funktionen nach jeder Änderung.