PHP’s security release of October 21, 2026 provides fixes in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and older branches receive no new official upstream release. Minimal source backports exist for PHP 7.4, 8.0, and 8.1, and some vendors may provide patched legacy packages. Those options are temporary safeguards, not a replacement for a supported runtime.

composer why-not php 8.4
composer audit
vendor/bin/rector process --dry-run
vendor/bin/rector process

CVE-2026–109618 affects the Zend memory manager. If memory exhaustion interrupts internal initialization, shutdown code may process an incomplete structure as valid data. Multipart/form-data handling is an important attack surface because request parsing can trigger substantial allocations before application code runs. Researchers demonstrated unauthenticated remote code execution against Apache mod_php. PHP-FPM normally terminates a worker when request startup fails, but memory exhaustion after successful startup can still create unsafe lifecycle conditions. The advisory therefore considers FPM susceptible, although it did not document a complete FPM exploit for this CVE.

The PHP 8.5.12 change replaces the immediate zend_bailout() path used in PHP 8.5.11 with delayed out-of-memory handling. The runtime records a pending state through EG(delayed_oom).state and requests handling at a safer VM point with EG(vm_interrupt). A separate hard limit can terminate the process with _exit(137) when continuing would risk corrupted state. The change alters runtime error handling rather than adding a narrow input check.

CVE-2026–109619 concerns request-owned state that remains referenced after its memory has been released. A later request in the same Apache or PHP-FPM worker can then encounter a stale pointer. Relevant runtime paths include error handling, fatal-error backtraces, session upload progress, and configuration diagnostics. Session upload progress may run during request-body processing before normal session initialization, so an application does not need to call session_start() explicitly for this surface to exist. The advisory documents a validated FPM exploitation path that depends on a suitable application operation leaving state behind after request startup.

The corresponding fix broadens request shutdown cleanup. zend_shutdown_executor_values() clears fields such as EG(last_fatal_error_backtrace), resets EG(num_errors), sets EG(errors) to NULL, and sets EG(exception) to NULL. The objective is to prevent request-owned state from remaining available across worker boundaries after abnormal execution.

Both vulnerabilities have a CVSS v4.0 score of 9.2. That score describes potential severity, not the exposure of every deployment. The first CVE has a confirmed pre-application path in mod_php. The second has confirmed paths in mod_php and PHP-FPM, with application and configuration requirements for FPM. Teams should check the runtime version, SAPI, reachable request paths, configuration, worker lifecycle, and known prerequisites. Configuration changes may reduce a documented attack path, but only a fixed runtime provides the intended remediation.

The operational burden differs sharply between maintained and neglected systems. A supported branch can usually be patched with a small change, such as moving PHP 8.4.26 to PHP 8.4.27, without combining the response with a major language migration. Teams should verify the runtime package or base image, run automated tests, exercise critical workflows, and deploy with monitoring and a recovery plan. In containers, the php:8.4-fpm tag is mutable. Caches, mirrors, registry delays, and pinned digests can leave a rebuild on an older version. A build-time version check and an immutable image digest make the artifact verifiable. Updating PHP on the host does not update the interpreter inside a container.

Testing should cover file uploads, imports, long-running jobs, exception paths, sessions, and integrations. After deployment, teams should watch failed requests, worker crashes, memory pressure, restarts, and business-level errors. A progressive rollout is preferable where the infrastructure permits it. Rollback must preserve a known artifact, but returning permanently to a vulnerable runtime is not an acceptable security response.

The migration problem is larger for PHP 8.1 and older. PHP 8.1 reached end of life on December 31, 2025, and older branches had already lost upstream support. A verified vendor backport can reduce immediate risk, but the strategic destination should be a supported branch. PHP 8.2 reaches end of life on December 31, 2026, so PHP 8.4 or PHP 8.5 is a more durable target when frameworks and dependencies allow it.

A compatibility assessment should identify Composer constraints, unsupported extensions, removed language features, deprecated behavior, framework requirements, and infrastructure dependencies. composer why-not php 8.4 can expose dependency blockers, while composer audit checks known package advisories. Neither command proves runtime compatibility. RectorPHP can apply AST-based transformations for many PHP language changes, using a configuration built around RectorConfig::configure(), withPaths(), withPhpSets(), or incremental withPhpLevel() levels. Dry runs and small migration batches make review easier. Rector does not upgrade the interpreter, resolve every dependency conflict, or replace regression testing. AI-assisted migration tools have the same limitation and require human review.

A major upgrade should be treated as an engineering program rather than a single code task. Code conversion, dependency work, and tests should be separated from the production cutover. Staging needs matching extensions, runtime settings, infrastructure behavior, and representative data. Teams should test failure paths and recovery behavior, then roll out progressively with technical and business monitoring.

The analysis notes that the PHP Foundation has acknowledged early indications of the out-of-memory problem in 2024, when no concrete exploitation path had been established. It attributed part of the delay to organizational and resource constraints and described changes to its security processes. Public fixes and documentation are positive developments, but they do not remove the need for stronger maintenance practices. The central business risk is not only compromise. It is being unable to deploy a security fix without starting an emergency modernization project.