Mitigation if you can’t update today
These settings come from php.net and the PHP security advisories. They reduce exposure to specific attack paths but do not make an installation safe. Updating to 8.2.35, 8.3.36, 8.4.27, 8.5.12 or a patched vendor package is the only complete fix.
CVE-2026-109618 (RCE via OOM corruption)
1. Remove the PHP memory limit administratively
Set memory_limit=-1 where applications can’t override it, for example php_admin_value in the FPM pool or Apache config. Make sure no pool, directory or application setting puts a finite limit back.
; FPM pool (e.g. /etc/php/8.3/fpm/pool.d/www.conf)
php_admin_value[memory_limit] = -1# Apache mod_php (vhost or server config)
php_admin_value memory_limit -12. Keep request sizes small
Without file uploads use post_max_size = 8M; with uploads post_max_size = 32M, and keep upload_max_filesize below it. Also enforce decoded request size, input field count, multipart part count, header count and nesting depth at the web server or proxy, including for requests without a usable Content-Length. If the application doesn’t use multipart forms, block them at the frontend.
post_max_size = 8M
upload_max_filesize = 2MThe advisory also recommends lowering max_input_nesting_level and bounding input variables, multipart parts and uploads.
3. Use a container or cgroup limit as the availability boundary
Prefer a policy that kills only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA: they make mmap() fail and trigger the vulnerable path.
CVE-2026-109619 (RCE via stale global state)
1. Disable session upload progress
Set it in php.ini, an FPM pool or server configuration applied before request parsing. ini_set() and FPM .user.ini do not work.
session.upload_progress.enabled = 02. PHP 8.5 only: disable fatal error backtraces
fatal_error_backtraces = 03. Remove INI settings that emit diagnostics before request start
Invalid or deprecated per-request settings (for example in .htaccess with mod_php, or PHP_VALUE sent by nginx to FPM) can trigger the bug. Examples from the advisory: auto_detect_line_endings=1, legacy assert.* settings on 8.3+, legacy session settings on 8.4+, explicit mbstring.http_input/iconv.*_encoding, and malformed memory_limit values.
4. Fix attacker-reachable fatal errors and timeouts
Including failures in callbacks, upload or import processing and cleanup. If performance allows, pm.max_requests=1 limits how long stale state can survive in an FPM worker.
Restart every worker
sudo systemctl restart php8.3-fpm # or: apache2 / httpd / lswsThen plan the real update: self-check commands · fixed versions.
FAQ
Does session.upload_progress.enabled=0 protect me?
Partly. It blocks the confirmed session path for CVE-2026-109619 but not other variants, and it does nothing for CVE-2026-109618. Set it in php.ini or the FPM pool (not with ini_set() or .user.ini) and restart every worker.
Why memory_limit=-1? Isn’t a lower limit safer?
For CVE-2026-109618 the controllable PHP memory-limit failure is the trigger. Removing the per-request limit removes that path. An underlying allocation failure can still reach the vulnerable code, so use a container or cgroup limit as an availability boundary.
Does hiding errors (display_errors=Off, @) help?
No. The advisory states that changing error_reporting, using @, or disabling display_errors or log_errors does not protect against CVE-2026-109619.