PHP Releases Emergency Fixes for Two Critical RCE Flaws

PHP has released emergency updates for two critical vulnerabilities that can allow an unauthenticated attacker to run code on a web server. The PHP security advisory published on 21 October names four fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Administrators running web-facing PHP installations should update without delay.

The release follows TechBooky’s earlier report on PHP’s advance warning. At that stage, the project had disclosed the severity of the flaws but withheld the affected versions and technical details. Those details are now public, so the job has shifted from preparing for an update to deploying and checking it.

What PHP has confirmed

The two issues are CVE-2026-109618, an out-of-memory corruption flaw, and CVE-2026-109619, which involves stale internal state surviving between requests. PHP says both can lead to remote code execution without authentication. The earlier notice rated each vulnerability 9.2 under CVSS v4.0. The advisory does not say that every vulnerable server has been compromised, but it does treat the exposure as urgent.

According to the project, all PHP installations serving web requests are at risk, including deployments using PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest with mod_php because it has demonstrated an exploit in which an unauthenticated request can trigger the attack before application code runs. That makes this a runtime issue, not simply a bug a site owner can fix by updating an individual WordPress plugin or changing a page.

For CVE-2026-109618, the vulnerable path begins when memory handling interrupts PHP while request data is only partly initialised; cleanup can then treat invalid data as valid. CVE-2026-109619 concerns request-owned state left behind after its memory has been freed. A later request handled by the same worker can encounter that stale state before normal initialisation. The linked OOM advisory and stale-state advisory provide the deeper technical detail.

Which version should administrators install?

The immediate target depends on the branch already in use. PHP 8.5 users should move to 8.5.12, PHP 8.4 users to 8.4.27, PHP 8.3 users to 8.3.36, and PHP 8.2 users to 8.2.35. The official downloads page carries the releases. Linux distributions and long-term-support vendors received patches in advance, so installations managed through a system package manager may receive a vendor build with a different package version or a backported fix. Administrators should check the relevant vendor advisory rather than relying on the upstream number alone.

PHP 8.1 and older are no longer maintained as normal supported branches by the core project. The team has nevertheless provided minimal source backports for PHP 7.4, 8.0 and 8.1 to help those building from source or lacking an LTS vendor. Some distribution and commercial vendors may also issue their own backports. Operators of older systems should establish whether their supplier has shipped a verified fix and plan a move to a supported branch. PHP also notes that 8.2 reaches end of life on 31 December 2026.

A practical response starts with an inventory of production, staging, containers and managed hosting accounts. Apply the appropriate update, restart affected PHP workers or services, confirm the running build rather than just the installed package, and test key site functions. Organisations using shared or managed hosting should ask the provider which PHP version is actually serving their sites and when the fix was deployed.

PHP has published temporary configuration measures for operators unable to update immediately, including steps concerning memory limits, upload settings and worker state. It is explicit that these measures cover particular attack paths only and do not make an installation safe. Some changes could also affect legitimate application behaviour. They should be assessed against the official guidance by the team responsible for the deployment, while the fixed release remains the priority.

The broader lesson is straightforward. A critical flaw in a common language runtime can sit beneath many otherwise well-maintained websites. Keeping an application or content management system current is necessary, but it does not replace patching the PHP process that serves it. The newly released builds turn yesterday’s warning into a concrete action item for hosts, developers and site operators.