We have already applied the patch to PHP that fixes this vulnerability, you can read our blog post for more information and a plain English explanation of what this vulnrability means.
These come from the PHP project’s advisory. Your host or developer applies them at server level. They reduce exposure to specific attack routes but do not make a server safe. Only the update does.
For CVE-2026-109618 (the out-of-memory issue):
- Remove the PHP memory limit. Set memory_limit=-1 in a way applications are unable to override, such as php_admin_value in the FPM pool or Apache configuration. Check no pool, directory or application puts a finite limit back. Underlying allocation failures still reach the vulnerable path, so this removes one trigger only.
- Lower the maximum request size. Set post_max_size to 8M for sites without file uploads, or 32M where uploads are needed. Keep upload_max_filesize below post_max_size. Also set limits at the web server or proxy for request size, input field count, multipart part count, header count and nesting depth. These limits must cover requests without a usable Content-Length.
- Use a container or cgroup limit as a safety boundary, ideally one that stops only the affected worker. Do not use RLIMIT_AS or RLIMIT_DATA, because these trigger the vulnerable allocation failure.
For CVE-2026-109619 (the stale data issue):
- Set session.upload_progress.enabled=0 and restart every worker. Apply the setting in php.ini, the FPM pool or server configuration, so the setting takes effect before request parsing. ini_set() and .user.ini files do not work for this. This blocks the confirmed session routes but not other variants.
- On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This blocks the confirmed fatal backtrace route only.
- Remove invalid or deprecated settings applied per request, as these produce warnings before PHP finishes initialising. Hiding warnings with error_reporting, display_errors or the @ operator does not help.
- Fix fatal errors and execution timeouts an attacker reaches, including failures in callbacks, upload or import handling and cleanup.
Source: PHP security advisory, https://www.php.net/archive/2026.php#2026-10-21-5
