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.

Not a fix. Treat these as a stopgap for hours or days, not weeks. Apply them administratively and restart every PHP worker.

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

2. 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 = 2M

The 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 = 0

2. PHP 8.5 only: disable fatal error backtraces

fatal_error_backtraces = 0

3. 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 / lsws

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