Two critical PHP vulnerabilities are forcing enterprise IT and security teams to treat their web-runtime inventories as an urgent incident-response problem. The PHP project said CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated remote code execution in installations serving web requests. For organizations with customer portals, e-commerce sites, content platforms or legacy business applications, the immediate task is to identify every exposed runtime, patch it and prove the fixed software is running in production.
The PHP project released fixed versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on Oct. 21. Its advisory says the risk covers web-serving deployments including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers mod_php the highest-risk deployment model because a demonstrated exploit can be triggered by an unauthenticated request before application code runs.
CVE-2026-109618 involves PHP’s handling of an out-of-memory condition while internal request data is only partly initialized. Cleanup can then treat invalid data as valid. CVE-2026-109619 involves request-owned state that can remain after its backing memory has been freed and later be used by the same worker before normal initialization resets it. Both conditions can give an attacker a route to execute code in the web process, according to the project.
The business exposure depends on what that process can reach. A compromised application tier may have access to customer information, content-management functions, service credentials, internal APIs or databases. Segmentation and least-privilege controls can limit the blast radius, but they do not remove the underlying defect. Teams should avoid assuming that a managed platform or a cloud deployment has already resolved the issue: custom images, self-managed containers and customer-controlled runtimes still need an update, rebuild and redeployment.
Older PHP branches present the more difficult operational case. PHP 8.1 and earlier no longer receive standard fixes from the PHP project, although distributions and long-term-support providers may offer backports. Matthew Weier O’Phinney, a PHP Foundation board member and product manager at Perforce Zend, said patching must be accompanied by an upgrade plan for applications that cannot move immediately. “Patching these vulnerabilities is the immediate priority, but organizations also need a plan for the PHP applications they cannot upgrade straight away. Long-term support can give teams breathing space to migrate safely while continuing to receive security fixes.”
Perforce Zend recommends first establishing where PHP runs and which versions remain supported, rather than relying on asset records or build specifications. Administrators should then install the relevant security updates rather than treat upload settings or memory-limit changes as a cure. The PHP project describes such settings as exposure-reduction measures for particular paths, not a complete fix.
The remaining safeguards are still useful while patching proceeds: restrict upload handling and the PHP process’s server access; confirm that older deployments have a source of tested security updates; and make migration into a supported branch a funded business objective. For containerized workloads, that means rebuilding from a patched base image, testing the application, redeploying the artifact and verifying the live version. For virtual machines and traditional web stacks, it means restarting the web-serving workers after package updates so old binaries are not left resident.
Organizations should prioritize public-facing applications, investigate unusual web-process behavior and retain a rollback plan for application changes. Web application firewall rules and tighter edge controls can buy time, but only as compensating controls. The durable response is a repeatable process that links application ownership, runtime discovery, patched builds and production verification. These PHP flaws are a security emergency; they are also a test of whether an enterprise can establish what code is actually serving requests at the edge.