PHP has released fixes for two critical PHP vulnerabilities that can allow unauthenticated remote code execution. The patched releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and PHP says updating is the only complete solution.
The flaws affect PHP installations that serve web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Both CVEs, CVE-2026-109618 and CVE-2026-109619, carry a CVSS v4.0 score of 9.2.
What happened
PHP’s security advisory says the two vulnerabilities can allow unauthenticated attackers to execute code on affected servers. The PHP development team released patched versions of PHP 8.2, 8.3, 8.4 and 8.5 on October 21, 2026.
Cloudflare reported seeing early attacks before PHP released the fixes, according to WIRED. Sansec expected mass exploitation to begin quickly after the release. The public exploit and technical details increase the need for immediate patching.
Update, October 22, 2026
CloudLinux reports that PHP released fixes for both critical vulnerabilities in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. It says PHP 8.1 and older receive no release from the PHP project, while minimal source backports are available for PHP 7.4, 8.0 and 8.1.
CloudLinux also reports fixed ea-php packages for cPanel EasyApache 4, from ea-php52 through ea-php85. After updating those packages, restart Apache and PHP-FPM so the patched code loads.
For servers using Imunify360 with the WAF enabled, CloudLinux says rulesets 8.83 through 8.85 arrived automatically on October 21. According to CloudLinux, its ModSecurity rules for Apache and Nginx, and its Coraza rules, block known exploit requests and the public exploit tool. CloudLinux calls this a “virtual patch”: it stops known request patterns at the server edge while the vulnerable PHP code stays as it is.
CloudLinux says this is an interim mitigation, not a fix. CloudLinux says it arrives without action on Imunify360 hosts with the WAF enabled. According to PHP, only an update is a complete solution, while the listed measures reduce exposure to specific attack paths but do not make an installation safe.
Are you affected?
PHP says all installations serving web requests are affected, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for mod_php because a demonstrated attack can run before application code starts. CloudLinux repeats that assessment in its update.
The patched releases are:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
Check with the NCSC’s recommendations for identifying PHP installations and monitoring systems that may be affected. It also recommends checking appliances and services that bundle PHP as a component.
PHP 8.1 and older receive no release from the PHP project. Its security team published minimal source backports for PHP 7.4, 8.0 and 8.1. Distribution and long-term-support vendors may also provide backported packages, so check with the provider rather than assuming the upstream release applies to the machine.
What to do now
-
Find every PHP installation that serves web requests, including PHP-FPM workers, Apache mod_php, cgi, FrankenPHP, LiteSpeed, hosting control panels, appliances and management interfaces. Prioritize internet-facing systems.
-
Update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, depending on the branch in use. Linux distributions and LTS vendors received the patches in advance, so use the provider’s fixed package where available.
-
Restart the affected web server or PHP service after updating. If the system runs multiple PHP versions for different sites, update each version that serves requests and verify each one.
-
If the host uses Imunify360 with the WAF enabled, review the official guidance for checking its protection status. CloudLinux says the rules arrived automatically, but the vulnerable PHP code remains until it is updated.
-
If PHP cannot be updated immediately, review the temporary measures in the official PHP advisory. PHP says those measures reduce exposure to specific paths but do not make the installation safe. If mitigation cannot be applied promptly, the NCSC says consider taking the system offline until it can be fully mitigated.
What are the two PHP vulnerabilities?
CVE-2026-109618: RCE via OOM corruption
CVE-2026-109618 affects PHP’s out-of-memory handling. PHP uses longjmp() to leave the current request context when an allocation fails. In some situations, request memory is temporarily reachable before it is fully initialized. The shutdown procedure can then read or branch on invalid state, leading to remote code execution.
Apache mod_php can reach the vulnerable shutdown path when automatic request-body parsing exhausts the configured memory limit. This can happen before application-specific code executes. PHP’s advisory says FPM is susceptible based on source analysis, although a complete FPM exploit has not been demonstrated for that interface. FrankenPHP is likely susceptible, while LSAPI application-specific exploits are considered likely but unvalidated.
CVE-2026-109619: RCE via stale global state
CVE-2026-109619 affects state retained by a PHP worker. State such as error, session, object or extension data can point to memory owned by one request. If that state is not reset before the request memory is released, a later request handled by the same worker may use the stale state before normal initialization replaces it.
A fatal error, including one caused by memory exhaustion, can interrupt an operation before its matching reset. A later warning or diagnostic can also leave error state available after shutdown. The demonstrated producer and consumer operations occur in separate HTTP requests handled by the same worker.
Why temporary settings are not enough
The PHP advisory lists measures that can reduce exposure to known attack paths. For CVE-2026-109618, these include setting memory_limit=-1 where applications cannot override it, lowering post_max_size, limiting decoded request size and multipart request structure, and using a container or cgroup limit as an availability boundary.
For CVE-2026-109619, PHP lists setting session.upload_progress.enabled=0, restarting every worker, and applying the setting before request parsing. On PHP 8.5, it also lists setting fatal_error_backtraces=0 and restarting workers. PHP says this blocks the confirmed session paths but not other variants.
Cloudflare and other web application firewall providers may add rules for known exploit patterns. Those rules can reduce exposure while the update is pending, but they do not alter the vulnerable PHP code. PHP and CloudLinux both state that the update is the complete solution.
What should be monitored after updating?
Keep monitoring web server and PHP logs for suspicious requests, especially multipart form uploads and unexpected changes to files or application behavior. The NCSC recommends monitoring internet-facing PHP systems for exploitation.
The FBI’s cyber assistant director Brett Leatherman advised isolating a system if signs of compromise are found, preserving web server and PHP logs, and reporting the incident to the local FBI field office. The agency says those reports help identify actors and warn other organizations.
Ubuntu has released fixes for supported releases through its package updates. Ubuntu’s advisory recommends upgrading all packages or targeting the PHP interpreter package, then restarting the affected application or rebooting the system so the updated components are loaded.
FAQ
What should an organization do if it cannot update PHP immediately?
PHP provides temporary settings for some attack paths, but says they do not make an installation safe. The NCSC says organizations that cannot apply the temporary measures promptly should consider taking the system offline until it can be fully mitigated.