RESPONSE REFERENCE · 21 OCTOBER 2026

Update PHP.
Verify the running workers.

Two request lifecycle vulnerabilities can allow unauthenticated remote code execution. All PHP installations serving web requests need attention.

Start with the patch

PHP’s advisory identifies PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed as in scope. It describes the highest risk for mod_php, including a demonstrated attack before application code runs.

Distribution packages may carry backported fixes without matching an upstream version. Verify the exact package, release, and vendor advisory. PHP 8.1 and older are no longer supported by the PHP project; use a confirmed vendor fix or upgrade. A newer-looking version string alone is not proof.

Update every installation and restart every affected worker. A fixed file on disk does not establish that an existing worker loaded it. Inventory may miss containers, custom bundles, and unexamined paths.

Understand the two failure paths

CVE-2026-109618 · Out-of-memory corruption

Interrupted initialization can leave request data in an invalid state that cleanup later treats as valid. Read the PHP technical advisory ↗

CVE-2026-109619 · Stale global state

Request-owned state can outlive its backing memory and be reused by a later request in the same worker. Read the PHP technical advisory ↗

If you cannot patch immediately

• Set session.upload_progress.enabled=0 in configuration applied before request parsing. Restart every worker. Runtime ini_set() and FPM .user.ini do not cover this requirement.
• On PHP 8.5, set fatal_error_backtraces=0 and restart every worker. This covers the confirmed backtrace path only.
• Remove invalid or deprecated per-request settings that emit early diagnostics. Hiding diagnostics does not fix the underlying path.
• Fix attacker-reachable fatal errors and timeouts, including callbacks, upload processing, imports, and cleanup.

Reduce exposure at the service boundary

Apply a low post_max_size: the advisory suggests 8M without uploads or 32M where uploads are required. Keep upload_max_filesize below it. Enforce decoded request size, field count, multipart part count, header count, and nesting limits at the web server or proxy, including requests without a usable Content-Length.

The advisory also describes memory_limit=-1, enforced where applications cannot override it. This removes the controllable PHP limit failure, but an underlying allocation failure can still trigger the vulnerability. It also changes availability risk. This tool does not enable it automatically.

Container or cgroup limits provide an availability boundary, preferably killing only the affected worker. Do not substitute RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable allocation failure. Isolation and request limits remain defense in depth.

Source: PHP security advisory, 21 October 2026. This independent tool is not affiliated with the PHP project.