Critical PHP Vulnerabilities: Patch First, Then Check Your Edge Defenses

On October 21, 2026, the PHP security team disclosed two critical vulnerabilities that can allow unauthenticated remote code execution. Any organization serving web requests with PHP should identify the affected installations and update them. A web application firewall can help reduce exposure during the response, but the PHP update is the fix.

This is not limited to WordPress or a particular plugin. The advisory names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed among web-facing installations at risk. PHP says the demonstrated risk is highest with Apache mod_php: one exploit path can be reached by an unauthenticated request before the application starts running.

What PHP disclosed

CVE-2026-109618 concerns out-of-memory handling. Under certain conditions, a request can interrupt PHP while internal request data is only partly initialized. Cleanup can then process that invalid state. The PHP advisory describes a demonstrated remote-code-execution path with Apache mod_php; it does not say every server configuration has the same demonstrated exploit.

CVE-2026-109619 concerns stale internal state. Request-owned data can remain accessible to a worker after its backing memory has been freed. A later request handled by that worker may use the stale state before normal initialization clears it. The PHP security team rates both vulnerabilities critical.

The difference between those mechanisms matters to responders, but the first business decision is the same: find where PHP is running. Include older sites, administrative tools, managed hosting, and services that do not appear in a main application inventory.

What to do now

1. Inventory exposed PHP installations and record the runtime, deployment model, and responsible owner. Check the version actually running in each environment, not just the version requested in a build file.
2. Install PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 for the relevant supported branch, or confirm that your Linux distribution or managed provider has shipped a fixed backport. PHP 8.1 and older no longer receive PHP-project updates; use a supported release or obtain explicit vendor guidance.
3. Restart affected workers after the update and verify the running version. Review application and security logs for suspicious requests or errors, but do not treat a probe or blocked request as proof of a successful exploit.

If an update cannot happen immediately, follow the PHP security team’s documented temporary mitigations for your configuration. PHP is explicit that these measures reduce exposure to specific paths but do not make an unpatched installation safe.

Where an edge security layer helps

Services such as Cloudflare and Akamai can inspect HTTP requests before they reach an origin server. Depending on the product and configuration, teams can use managed web application firewall rules, narrowly scoped custom rules, rate controls, and security-event reporting to filter or investigate hostile traffic. That gives responders another control while updates are being deployed.

Rules must be enabled and scoped to the right hostnames and paths, legitimate traffic must be checked for false positives, and requests must actually pass through the edge. An exposed origin that accepts direct requests may bypass those protections. No edge provider can guarantee that every exploit variant will be caught, and filtering cannot repair vulnerable PHP code.

Treat the edge as a useful buffer, not a substitute for maintenance. Patch the runtime, verify the fix, and keep the traffic controls in place as part of a broader defense.