PHP released versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on October 21, following its advance notice. The project says the updates address CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities that can permit unauthenticated remote code execution. Its advisory urges immediate updating and says partial mitigations are not a complete solution.
The advisory covers PHP installations serving web requests and identifies mod_php as the highest-risk configuration, with a demonstrated attack before application code runs. Distribution and long-term-support vendors may supply patched packages under their own versioning. PHP also supplied limited source backports for older branches; that exceptional step does not restore general upstream support for those releases.
A separate October 23 notice identifies CVE-2026-115560: a rare session-handler configuration remains exposed pending a regular release. PHP recommends disabling session upload progress temporarily; applications that never change serialization handlers at runtime are exempt from that recommendation. This later issue does not negate the need for the October 21 fixes. The linked notice details the required combination of settings and application behavior.
An October 24 honeypot report by researcher Adel Karimi documents successful remote code execution against deliberately favorable PHP 8.4.26 installations using single-worker Apache mod_php. The report correlates network requests with newly started shell processes and says the observed chain is consistent with CVE-2026-109618. It does not establish a separate CVE-2026-109619 path or measure reliability across other deployments. This is evidence from monitored decoy systems, not a count of compromised customer websites.
CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on October 26. The entries identify exploitation evidence and mark forensic triage as required under the applicable federal guidance. Their listed remediation date is October 29. These records do not identify the scale of exploitation or establish that any particular organization was compromised.
NAOAT analysis
The release changes the operational task from preparing a maintenance window to verifying deployed fixes. A team needs to know which runtime handles each public application, which packaging source owns its updates and who can confirm the version running after maintenance. A command-line version check alone may describe a different installation from the one serving web requests.
Where a distribution backports a fix, the upstream version number may be an incomplete signal. The change record should retain the vendor advisory and installed package revision together. That gives reviewers an explanation for why a system is considered patched without requiring them to infer security status from a shortened version string.
An organization can also separate installation from service validation. Updating packages, restarting the relevant processes and exercising representative requests are distinct checkpoints with different owners. Recording each one helps expose partially completed work. For older applications that cannot move promptly, the linked project advisory and the responsible support vendor are the appropriate basis for a temporary response; a workaround should not quietly become the permanent maintenance plan.