Wenn Sie heute nicht aktualisieren können
Temporäre Workarounds
Diese Maßnahmen verringern die Angriffsfläche für bestimmte bekannte Pfade, während Sie das Update ausrollen. Keine ist vollständig, und manche haben echte Nachteile. Vor dem Ausrollen testen.
Zuletzt geprüft 2026-10-22
Es gibt keine vollständige Lösung per Konfiguration
Beide PHP-Advisories sagen das ausdrücklich. Nutzen Sie das, um Stunden oder Tage zu gewinnen, nicht Wochen. Patch-Anleitung →
Was jede Maßnahme bewirkt
| Maßnahme | Wirkung | CVE | Kosten / Nebenwirkungen |
|---|---|---|---|
Primär | Die primäre Konfigurationsmaßnahme laut Advisory. Entfernt PHPs eigenen OOM-Abbruch, auf den die meisten Angriffspfade setzen. | Beide | Stattdessen beendet das OS ausufernde Worker, was Requests unterbricht. Ohne cgroup-Limit kann ein einzelner Request den ganzen Host erschöpfen. |
Teilweise | Blockiert die bestätigten Session-Pfade, „aber nicht andere Varianten“ (php.net). Muss in php.ini, FPM-Pool oder Serverkonfiguration stehen — nicht in .user.ini oder per ini_set(). | …619 | Bricht Upload-Fortschrittsbalken, die darauf aufbauen (selten). Nach dem Patch ausgeschaltet lassen, wenn ungenutzt. |
Teilweise | Blockiert nur den bestätigten Fatal-Backtrace-Pfad — den stärksten demonstrierten Fall von CVE-2026-109619. | …619 | Fatale Fehler enthalten keinen Backtrace mehr. |
Niedrigeres Teilweise | Weniger vom Angreifer gesteuerter Speicherdruck beim Multipart-Parsing, bevor Ihre Anwendung läuft. php.net empfiehlt 8M ohne Uploads, 32M mit Uploads. | …618 | Begrenzt auch Uploads — legitime Upload-Abläufe testen. |
Eingaben begrenzen: Teilweise | Begrenzt weiteres Speicherwachstum durch den Parser. | …618 | Große oder tief verschachtelte Formulare können scheitern. |
Von Angreifern auslösbare fatale Fehler und ungültige/veraltete Einstellungen pro Request entfernen Teilweise | Entfernt Auslöser des veralteten Zustands hinter CVE-2026-109619: Diagnosen vor der Initialisierung, fatale Fehler und Timeouts in Callbacks, Uploads, Importen und Aufräumcode. | …619 | Aufwand für Code- und Konfigurations-Review. |
Niedrigeres Teilweise | Erneuert Worker, damit korrupter Zustand weniger Requests überlebt. 1 ist der Extremwert, den das Advisory nennt. | …619 | Spürbare CPU- und Latenzkosten; hilft nicht gegen Angriffe mit einem einzigen Request. |
Begrenzt Schaden | Verhindert, dass Fehlerausgaben Details an Benutzer verraten. Hinweis: Diagnosen zu verbergen stoppt den Auslöser von CVE-2026-109619 nicht. | Schaden | Keine in Produktion. |
SELinux / AppArmor zur Einschränkung des PHP-Workers Begrenzt Schaden | Begrenzt, was eingeschleuster Code ausführen oder lesen kann. | Schaden | Aufwand für Policies; stoppt keine Speicherlecks. |
Verwaltete WAF- / CDN-Regeln Teilweise | Blockiert bekannte Payload-Muster am Rand. Cloudflare deckt auch Free-Pläne ab. | Beide | Angreifer verändern Payloads bereits; die Abdeckung variiert je Anbieter. |
Das sollten Sie nicht tun
memory_limit nicht durch RLIMIT_AS / RLIMIT_DATA ersetzen
Also kein ulimit -v / ulimit -d, kein systemd LimitAS= / LimitDATA= und keine rlimit_*-Tricks. Sie lassen mmap() in PHP fehlschlagen, was denselben anfälligen OOM-Pfad auslöst. Nutzen Sie stattdessen ein cgroup-Limit (MemoryMax=, Container --memory).
Konfiguration zum Kopieren
; /etc/php/8.3/fpm/conf.d/99-php2shell.ini (path varies)
; TEMPORARY PHP2Shell mitigations — revisit after upgrading.
; Tune every number to what your application really needs.
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; PHP 8.5 only, ignored elsewhere
display_errors = 0
post_max_size = 8M ; php.net: 8M without uploads, 32M with
upload_max_filesize = 6M ; keep below post_max_size
max_input_nesting_level = 32 ; default 64
max_input_vars = 1000
max_file_uploads = 5 ; default 20
max_multipart_body_parts = 200; /etc/php/8.3/fpm/pool.d/www.conf (one block per pool)
; php_admin_* cannot be overridden by ini_set() in application code.
; WordPress and others call ini_set('memory_limit', ...) — a plain
; php.ini value would be silently replaced with a finite limit again.
php_admin_value[memory_limit] = -1
php_admin_flag[session.upload_progress.enabled] = off
; Recycle workers more often (performance cost — measure it)
pm.max_requests = 50# Apache + mod_php (VirtualHost or global config)
php_admin_value memory_limit -1
php_admin_flag session.upload_progress.enabled off
# 32 MiB request body cap (match post_max_size)
LimitRequestBody 33554432
# nginx in front of PHP-FPM
client_max_body_size 32m;# Cap total PHP-FPM memory with cgroup v2 (systemd's MemoryMax = memory.max)
sudo systemctl edit php8.3-fpm
# [Service]
# MemoryHigh=3G
# MemoryMax=4G
sudo systemctl restart php8.3-fpm
systemctl show php8.3-fpm -p MemoryMax
# Containers: set a memory limit on the container instead
docker run --memory=4g ...Starten Sie PHP-FPM / Apache nach jeder Änderung neu. Prüfen Sie den wirksamen Wert mit php-fpm8.3 -i | grep -E 'memory_limit|upload_progress' — beachten Sie, dass -i die php.ini liest, aber keine Pool-Overrides; prüfen Sie daher auch phpinfo() über die Website.
Nach dem Update
- Setzen Sie
memory_limitwieder auf einen endlichen Wert, der zu Ihrer Anwendung passt. Das gepatchte PHP fügt darüber ein hartes Limit hinzu. - Halten Sie
post_max_sizedeutlich unter dem Speicherbudget undmax_input_nesting_levelbei dem, was Sie wirklich brauchen. - Lassen Sie
session.upload_progress.enabled = 0stehen, wenn Sie es nicht nutzen. Weniger Angriffsfläche, keine Kosten. - Setzen Sie
pm.max_requestsauf Ihren üblichen Wert zurück. - Optional:
expose_php = 0verbirgt Ihre Version vor Scannern. Das ist Hygiene, kein Fix.