Als je vandaag niet kunt upgraden

Tijdelijke mitigaties

Deze maatregelen verkleinen de blootstelling aan specifieke bekende aanvalspaden terwijl je de upgrade uitrolt. Geen ervan is volledig, en sommige hebben echte nadelen. Test ze voordat je ze uitrolt.

Laatst gecontroleerd 2026-10-22

Er is geen volledige oplossing via configuratie

Beide PHP-advisories zeggen dat expliciet. Gebruik dit om uren of dagen te winnen, geen weken. Patchgids →

Wat elke maatregel doet

Maatregel	Effect	CVE	Kosten / bijwerkingen
`memory_limit = -1` (administratief ingesteld) + cgroup-geheugenlimiet Primair	De primaire configuratiemitigatie in de advisory. Schakelt PHP’s eigen OOM-afbreking uit, waar de meeste aanvalspaden op leunen.	Beide	Het OS beëindigt dan op hol geslagen workers, wat requests onderbreekt. Zonder cgroup-limiet kan één request de hele host uitputten.
`session.upload_progress.enabled = 0` Gedeeltelijk	Blokkeert de bevestigde sessiepaden, “maar niet andere varianten” (php.net). Moet in php.ini, de FPM-pool of serverconfig staan — niet in `.user.ini` of via `ini_set()`.	…619	Breekt uploadvoortgangsbalken die erop leunen (zeldzaam). Laat het na het patchen uit als je het niet gebruikt.
`fatal_error_backtraces = 0` (PHP 8.5) Gedeeltelijk	Blokkeert alleen het bevestigde fatal-backtrace-pad — het sterkst gedemonstreerde geval van CVE-2026-109619.	…619	Fatale fouten bevatten geen backtrace meer.
Lagere `post_max_size` + limiet op de body aan de frontend Gedeeltelijk	Minder door de aanvaller gestuurde geheugendruk tijdens het parsen van multipart, nog voordat je app draait. php.net adviseert 8M zonder uploads, 32M met uploads.	…618	Beperkt ook uploads — test legitieme uploadflows.
Begrens input: `max_input_nesting_level`, `max_input_vars`, `max_file_uploads`, `max_multipart_body_parts` Gedeeltelijk	Beperkt andere geheugengroei door de parser.	…618	Grote of diep geneste formulieren kunnen falen.
Verwijder door aanvallers bereikbare fatale fouten en ongeldige/verouderde instellingen per request Gedeeltelijk	Haalt de bronnen weg van de achtergebleven state achter CVE-2026-109619: diagnostiek vóór de initialisatie, fatale fouten en timeouts in callbacks, uploads, imports en opruimcode.	…619	Inspanning voor code- en configuratiereview.
Lagere `pm.max_requests` (FPM) Gedeeltelijk	Vernieuwt workers zodat corrupte state minder requests overleeft. 1 is de extreme waarde die de advisory noemt.	…619	Echte CPU- en latencykosten; helpt niet tegen aanvallen met één request.
`display_errors = 0` Beperkt impact	Voorkomt dat foutmeldingen details lekken naar gebruikers. Let op: diagnostiek verbergen stopt de trigger van CVE-2026-109619 niet.	Impact	Geen in productie.
SELinux / AppArmor-afscherming van de PHP-worker Beperkt impact	Beperkt wat geïnjecteerde code kan uitvoeren of lezen.	Impact	Werk aan policies; stopt geen geheugenlekken.
Beheerde WAF- / CDN-regels Gedeeltelijk	Blokkeert bekende payloadvormen aan de rand. Cloudflare dekt ook Free-abonnementen.	Beide	Aanvallers passen payloads al aan; dekking verschilt per aanbieder.

Doe dit niet

Vervang memory_limit niet door RLIMIT_AS / RLIMIT_DATA

Dus geen ulimit -v / ulimit -d, systemd LimitAS= / LimitDATA= of rlimit_*-trucs. Die laten mmap() in PHP falen, wat hetzelfde kwetsbare OOM-pad activeert. Gebruik in plaats daarvan een cgroup-limiet (MemoryMax=, container --memory).

Configuratie om te kopiëren

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-geheugenlimiet

# 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 ...

Herstart PHP-FPM / Apache na elke wijziging. Controleer de effectieve waarde met php-fpm8.3 -i | grep -E 'memory_limit|upload_progress' — let op: -i leest php.ini maar geen pool-overrides, dus controleer ook phpinfo() via de site.

Na de upgrade

Zet memory_limit terug op een eindige waarde die bij je app past. De gepatchte PHP voegt daarboven een harde limiet toe.
Houd post_max_size ruim onder het geheugenbudget, en max_input_nesting_level op wat je echt nodig hebt.
Laat session.upload_progress.enabled = 0 staan als je het niet gebruikt. Minder aanvalsoppervlak, geen kosten.
Zet pm.max_requests terug op je normale waarde.
Optioneel: expose_php = 0 verbergt je versie voor scanners. Het is hygiëne, geen oplossing.