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ßnahmeWirkungCVEKosten / Nebenwirkungen

memory_limit = -1 (administrativ gesetzt) + cgroup-Speicherlimit

Primär
Die primäre Konfigurationsmaßnahme laut Advisory. Entfernt PHPs eigenen OOM-Abbruch, auf den die meisten Angriffspfade setzen.BeideStattdessen beendet das OS ausufernde Worker, was Requests unterbricht. Ohne cgroup-Limit kann ein einzelner Request den ganzen Host erschöpfen.

session.upload_progress.enabled = 0

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().…619Bricht Upload-Fortschrittsbalken, die darauf aufbauen (selten). Nach dem Patch ausgeschaltet lassen, wenn ungenutzt.

fatal_error_backtraces = 0 (PHP 8.5)

Teilweise
Blockiert nur den bestätigten Fatal-Backtrace-Pfad — den stärksten demonstrierten Fall von CVE-2026-109619.…619Fatale Fehler enthalten keinen Backtrace mehr.

Niedrigeres post_max_size + Body-Limit am Frontend

Teilweise
Weniger vom Angreifer gesteuerter Speicherdruck beim Multipart-Parsing, bevor Ihre Anwendung läuft. php.net empfiehlt 8M ohne Uploads, 32M mit Uploads.…618Begrenzt auch Uploads — legitime Upload-Abläufe testen.

Eingaben begrenzen: max_input_nesting_level, max_input_vars, max_file_uploads, max_multipart_body_parts

Teilweise
Begrenzt weiteres Speicherwachstum durch den Parser.…618Groß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.…619Aufwand für Code- und Konfigurations-Review.

Niedrigeres pm.max_requests (FPM)

Teilweise
Erneuert Worker, damit korrupter Zustand weniger Requests überlebt. 1 ist der Extremwert, den das Advisory nennt.…619Spürbare CPU- und Latenzkosten; hilft nicht gegen Angriffe mit einem einzigen Request.

display_errors = 0

Begrenzt Schaden
Verhindert, dass Fehlerausgaben Details an Benutzer verraten. Hinweis: Diagnosen zu verbergen stoppt den Auslöser von CVE-2026-109619 nicht.SchadenKeine in Produktion.

SELinux / AppArmor zur Einschränkung des PHP-Workers

Begrenzt Schaden
Begrenzt, was eingeschleuster Code ausführen oder lesen kann.SchadenAufwand für Policies; stoppt keine Speicherlecks.

Verwaltete WAF- / CDN-Regeln

Teilweise
Blockiert bekannte Payload-Muster am Rand. Cloudflare deckt auch Free-Pläne ab.BeideAngreifer 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

php.ini-Drop-in
; /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
php-fpm-Pool
; /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 / nginx
# 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;
cgroup-Speicherlimit
# 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_limit wieder auf einen endlichen Wert, der zu Ihrer Anwendung passt. Das gepatchte PHP fügt darüber ein hartes Limit hinzu.
  • Halten Sie post_max_size deutlich unter dem Speicherbudget und max_input_nesting_level bei dem, was Sie wirklich brauchen.
  • Lassen Sie session.upload_progress.enabled = 0 stehen, wenn Sie es nicht nutzen. Weniger Angriffsfläche, keine Kosten.
  • Setzen Sie pm.max_requests auf Ihren üblichen Wert zurück.
  • Optional: expose_php = 0 verbirgt Ihre Version vor Scannern. Das ist Hygiene, kein Fix.