PHP’s advisory is direct: updating to a release that contains the patch is the only complete solution. The settings below reduce specific attack paths. They do not make an installation safe. Apply them in php.ini, an FPM pool, or server configuration that the application cannot override with ini_set() or .user.ini. Restart every worker after the change.
For CVE-2026-109618
Set memory_limit=-1 with php_admin_value or the equivalent administrative mechanism. Then search pools, virtual hosts, and application config for a finite memory_limit that puts the controllable limit back. This removes the predictable per-request failure used by the confirmed exploit. An underlying mmap failure can still reach the vulnerable longjmp path.
Keep post_max_size conservative. PHP’s examples are 8M when the application does not need uploads, and 32M when it does, with upload_max_filesize below post_max_size. Also bound request size, field count, part count, header count, and nesting at the frontend, including requests that do not send a usable Content-Length.
A cgroup or container memory limit can bound availability. Prefer a policy that kills the affected worker rather than every worker and the master. Do not use RLIMIT_AS or RLIMIT_DATA.
For CVE-2026-109619
Set session.upload_progress.enabled=0 before request parsing, then restart workers. This blocks the confirmed session paths and not other variants.
On PHP 8.5 only, set fatal_error_backtraces=0 and restart workers. That removes the confirmed backtrace producer and not every other state family.
Remove obsolete per-request INI that emits diagnostics. Hiding those diagnostics does not help. Where you can, remove attacker-reachable fatal errors and execution timeouts inside upload, import, callback, and shutdown paths. pm.max_requests=1 limits how long stale state could survive and is expensive.
Agency guidance when you still cannot patch
CISA said a web application firewall may provide some protection until the update, and that unsupported PHP which cannot be updated should be taken offline until it is patched or upgraded. Isolation is a containment decision. It is not a patched runtime.
After any of these settings, confirm the running worker actually loaded them. A pool that still has the old php.ini is unchanged.
Questions
Should session upload progress stay off after patching?
PHP says it may be prudent to leave session.upload_progress.enabled=0 if the application does not need the feature, including after the patch.