A site can show green lights for every WordPress core, theme and plugin update while the server beneath it remains vulnerable. This release is a reminder that application maintenance and runtime maintenance are different responsibilities.
What actually happened
On October 21, the PHP security team released fixes for CVE-2026-109618 and CVE-2026-109619, two critical flaws that can allow unauthenticated remote code execution. The patched release versions are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The flaws affect PHP web-request handling, rather than a particular WordPress plugin.
The maintainers identify mod_php as especially exposed because an unauthenticated request can trigger the demonstrated attack before application code runs. Cloudflare deployed WAF mitigations, including protections available to Free-plan customers, but the PHP maintainers say there is no complete mitigation other than updating. The WAF does not repair a vulnerable server.
Why a small team cares
Consider a WooCommerce shop that outsourced its hosting and faithfully updates WordPress every month. Its store software might be current, but an older PHP package could still be loaded by Apache or PHP-FPM. A flaw below WordPress may bypass the protection the owner assumes comes from keeping plugins current.
This is particularly awkward for small businesses because the host, not the store administrator, may control the runtime. A dashboard label showing PHP 8.3 is also insufficient evidence: the security fix is tied to the actual installed patch level or a documented vendor-backported package. Shared-hosting customers need an explicit answer from the provider.
The impact can extend beyond downtime. A server-level compromise threatens customer records, store credentials and other connected services. It also makes a simple plugin-only response misleading, because no WordPress update can correct an underlying PHP memory-handling defect.
Hype vs useful
Critical severity is justified here, but a vulnerability announcement does not prove every site has been exploited. Configuration and hosting details matter. The sensible response is to establish which runtime serves each site and confirm that it has been patched, rather than assume every PHP version string implies equal risk.
PHP 8.2 reaches end of life on December 31, 2026, so shops remaining there should plan a supported upgrade even after applying 8.2.35. For PHP 8.1 and older, a vendor backport needs to be specifically confirmed; an unsupported upstream branch should not be treated as protected because a hosting provider says it is managed.
Cloudflare's protective rules can buy time, especially during maintenance windows, but origin exposure, rule scope and traffic paths still matter. The outcome to demand is a patched running PHP process with the website functioning afterward.
