PHP’s critical security alarm: Two flaws and the reality of patching
The PHP security alarm in the October 22, 2026 news cycle concerns the language runtime beneath websites, rather than a defect limited to one application or extension. CVE-2026-109618 and CVE-2026-109619 can allow unauthenticated remote code execution under suitable conditions. Each carries a CVSS v4.0 base score of 9.2, rated critical. Fixes were released on October 21; the practical question today is which deployed systems have actually received them.
Discovery, attempted exploitation, and a confirmed compromise are separate facts. Observed attack traffic increases the urgency, but does not establish that every PHP website has been breached. Successful execution initially operates with the web worker account’s permissions; it does not automatically grant administrator or root access.
First flaw: Unsafe interruption when memory runs out
CVE-2026-109618 involves the longjmp() escape used for out-of-memory errors. PHP can interrupt work while internal request data is accessible but incompletely initialized. Request shutdown may then use that invalid data. Crafted multipart requests, headers with disproportionate memory costs, or application-specific memory consumption can contribute to this condition.
Full remote code execution has been demonstrated against Apache mod_php, including a path triggered before application code runs. The patch changes out-of-memory handling to remove that unsafe early-exit path.
Second flaw: Invalid state crossing a request boundary
CVE-2026-109619 involves worker globals retaining references to memory after the owning request has released it. When the same worker processes another request, an operation can access that stale state before normal initialization resets it. This is a use-after-free problem.
Exploitation needs an operation that leaves unsafe state and a later operation that consumes it. Session upload progress and early configuration diagnostics are confirmed paths. PHP 8.5 fatal error backtraces provide another confirmed case. Hiding error messages does not remove the invalid memory access.
Which installations deserve priority?
Internet-facing PHP installations take priority, including PHP-FPM, mod_php, php-cgi, FrankenPHP, and LiteSpeed. Their exploitation conditions differ. The absence of a complete FPM exploit demonstration for the first flaw does not establish FPM immunity; the second advisory includes a validated FPM path involving a suitable application operation.
The inventory should include PHP embedded beneath content management systems, online stores, and business portals. An application update does not close these runtime vulnerabilities unless it also delivers the relevant PHP fix.
Which releases contain the fixes?
The fixed releases in supported branches are:
| Installed branch | Release fixing these two flaws |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Earlier releases within these branches require assessment. Distribution packages may backport a fix while preserving an older upstream version number, so the provider’s package advisory matters alongside the version string. PHP 8.1 and older branches are outside normal project support. Limited source patches or vendor support for certain older branches do not restore their regular upstream security lifecycle.
Why temporary settings are incomplete
Setting session.upload_progress.enabled=0 can block known session paths, while fatal_error_backtraces=0 on PHP 8.5 addresses a particular backtrace path. Neither covers every variant, and relevant workers must be restarted. Likewise, memory_limit=-1 is not a universal configuration recipe: reducing one trigger can introduce memory-consumption and availability tradeoffs, while underlying allocation failures remain relevant. A web application firewall does not replace patching.
My operational priority would be to identify exposed systems, install the appropriate security package, restart relevant services, and verify the runtime actually handling visitor traffic. A command-line php -v result alone cannot prove that every pool or container is fixed. If suspicious evidence exists, installing a patch does not clean up a possible earlier compromise; incident investigation is a separate task.
The lesson is that patch management extends beyond downloading an update. Protection depends on delivering it to every running copy and verifying that deployment.
The cover is an AI-generated illustrative scene, not a photograph of an actual attack or organization.