The PHP project has released emergency security updates for two critical flaws in the language runtime that can allow an unauthenticated attacker to execute code on a vulnerable server. The fixes arrived on October 21 in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.
The advisory applies broadly to PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The project said the demonstrated risk is highest with mod_php because an attack can be triggered before application code begins running.
Two flaws in request handling
CVE-2026-109618 involves out-of-memory handling. PHP can be interrupted while internal request data is only partly initialized, after which cleanup may mistake invalid data for valid state. CVE-2026-109619 involves request-owned state that can remain after its backing memory has been freed and then be reused by a later request.
Both issues were described as critical and rated 9.2 under CVSS version 4.0 in the project’s advance notice. Because the vulnerabilities sit in the runtime, patching a WordPress plugin, framework or individual application does not address the underlying problem. Administrators must update PHP itself or obtain a confirmed backport from their operating-system or long-term-support vendor.
PHP 8.1 and older branches no longer receive regular fixes from the PHP project. The security team nevertheless published minimal source backports for PHP 7.4, 8.0 and 8.1 to help operators who build from source or lack an LTS package. The preferred path remains moving to a supported, patched release.
Mitigations are not a substitute for updates
The project listed temporary steps that can reduce exposure to specific attack paths, such as changing memory and upload limits, disabling session upload progress and restarting workers. It stressed that these measures are incomplete and do not make an affected installation safe.
Operators should first identify the PHP version actually running behind every web endpoint, not only the command-line version. They should then check their Linux distribution or hosting provider for a patched package, deploy it, restart the relevant workers and verify that the updated runtime is active. Vendors sometimes backport fixes without changing the upstream version string, so confirmation from the package maintainer may be necessary.
The incident is particularly important for shared hosting and content-management systems because PHP processes can sit in front of large numbers of public requests. A prompt runtime update, followed by normal application testing and monitoring, is the clearest way to reduce risk without relying on partial workarounds.
Source: PHP project security advisory and release notices.
Disclosure: The featured image is an AI-generated editorial illustration.
