{"id":817,"date":"2026-10-21T13:17:16","date_gmt":"2026-10-21T13:17:16","guid":{"rendered":"https:\/\/managedt.com\/blog\/php-emergency-patches-109618-109619\/"},"modified":"2026-10-22T14:51:39","modified_gmt":"2026-10-22T14:51:39","slug":"php-emergency-patches-109618-109619","status":"publish","type":"post","link":"https:\/\/managedt.com\/blog\/php-emergency-patches-109618-109619\/","title":{"rendered":"Critical PHP Vulnerabilities Patch Now: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Released for Two Unauthenticated RCE Flaws"},"content":{"rendered":"<div class=\"post-updated\"><em>Updated October 22, 2026 at 10:48 AM ET<\/em><\/div>\n<p>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.<\/p>\n<p>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.<\/p>\n<h2>What happened<\/h2>\n<p><a href=\"https:\/\/www.php.net\/archive\/2026.php#2026-10-21-5\" target=\"_blank\" rel=\"noopener\">PHP\u2019s security advisory<\/a> 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.<\/p>\n<p>Cloudflare reported seeing early attacks before PHP released the fixes, according to <a href=\"https:\/\/www.wired.com\/story\/this-is-not-a-drill-2-php-vulnerabilities-are-setting-the-internet-on-fire\/\" target=\"_blank\" rel=\"noopener\">WIRED<\/a>. Sansec expected mass exploitation to begin quickly after the release. The public exploit and technical details increase the need for immediate patching.<\/p>\n<h2>Update, October 22, 2026<\/h2>\n<p><a href=\"https:\/\/blog.cloudlinux.com\/php-cve-2026-109618-and-cve-2026-109619\" target=\"_blank\" rel=\"noopener\">CloudLinux reports<\/a> 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.<\/p>\n<p>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.<\/p>\n<p>For servers using Imunify360 with the WAF enabled, CloudLinux says rulesets 8.83 through 8.85 arrived automatically on October 21. <a href=\"https:\/\/blog.cloudlinux.com\/php-cve-2026-109618-and-cve-2026-109619\" target=\"_blank\" rel=\"noopener\">According to CloudLinux<\/a>, its ModSecurity rules for Apache and Nginx, and its Coraza rules, block known exploit requests and the public exploit tool. <a href=\"https:\/\/blog.cloudlinux.com\/php-cve-2026-109618-and-cve-2026-109619\" target=\"_blank\" rel=\"noopener\">CloudLinux calls this a \u201cvirtual patch\u201d<\/a>: it stops known request patterns at the server edge while the vulnerable PHP code stays as it is.<\/p>\n<p><a href=\"https:\/\/blog.cloudlinux.com\/php-cve-2026-109618-and-cve-2026-109619\" target=\"_blank\" rel=\"noopener\">CloudLinux says this is an interim mitigation, not a fix<\/a>. CloudLinux says it arrives without action on Imunify360 hosts with the WAF enabled. <a href=\"https:\/\/www.php.net\/archive\/2026.php#2026-10-21-5\" target=\"_blank\" rel=\"noopener\">According to PHP<\/a>, only an update is a complete solution, while the listed measures reduce exposure to specific attack paths but do not make an installation safe.<\/p>\n<h2>Are you affected?<\/h2>\n<p>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.<\/p>\n<p>The patched releases are:<\/p>\n<ul>\n<li>PHP 8.2: 8.2.35<\/li>\n<li>PHP 8.3: 8.3.36<\/li>\n<li>PHP 8.4: 8.4.27<\/li>\n<li>PHP 8.5: 8.5.12<\/li>\n<\/ul>\n<p>Check with the NCSC\u2019s 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.<\/p>\n<p>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.<\/p>\n<h2>What to do now<\/h2>\n<ol>\n<li>\n<p>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.<\/p>\n<\/li>\n<li>\n<p>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\u2019s fixed package where available.<\/p>\n<\/li>\n<li>\n<p>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.<\/p>\n<\/li>\n<li>\n<p>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.<\/p>\n<\/li>\n<li>\n<p>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.<\/p>\n<\/li>\n<\/ol>\n<h2>What are the two PHP vulnerabilities?<\/h2>\n<h2>CVE-2026-109618: RCE via OOM corruption<\/h2>\n<p>CVE-2026-109618 affects PHP\u2019s out-of-memory handling. PHP uses <code>longjmp()<\/code> 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.<\/p>\n<p>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\u2019s 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.<\/p>\n<h2>CVE-2026-109619: RCE via stale global state<\/h2>\n<p>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.<\/p>\n<p>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.<\/p>\n<h2>Why temporary settings are not enough<\/h2>\n<p>The PHP advisory lists measures that can reduce exposure to known attack paths. For CVE-2026-109618, these include setting <code>memory_limit=-1<\/code> where applications cannot override it, lowering <code>post_max_size<\/code>, limiting decoded request size and multipart request structure, and using a container or cgroup limit as an availability boundary.<\/p>\n<p>For CVE-2026-109619, PHP lists setting <code>session.upload_progress.enabled=0<\/code>, restarting every worker, and applying the setting before request parsing. On PHP 8.5, it also lists setting <code>fatal_error_backtraces=0<\/code> and restarting workers. <a href=\"https:\/\/www.php.net\/archive\/2026.php#2026-10-21-5\" target=\"_blank\" rel=\"noopener\">PHP says this blocks the confirmed session paths but not other variants.<\/a><\/p>\n<p>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.<\/p>\n<h2>What should be monitored after updating?<\/h2>\n<p>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.<\/p>\n<p>The FBI\u2019s 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.<\/p>\n<p>Ubuntu has released fixes for supported releases through its package updates. Ubuntu\u2019s 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.<\/p>\n<h2>FAQ<\/h2>\n<h3>What should an organization do if it cannot update PHP immediately?<\/h3>\n<p>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.<\/p>\n<div class=\"source-disclaimer\"><em>This article reports on publicly available information from the sources listed below. We have no reason to believe it is inaccurate, but we have not independently verified every claim, and details may change as the story develops.<\/em><\/div>\n<section class=\"post-sources\">\n<h2>Sources<\/h2>\n<ul>\n<li><a href=\"https:\/\/www.wired.com\/story\/this-is-not-a-drill-2-php-vulnerabilities-are-setting-the-internet-on-fire\/\" target=\"_blank\" rel=\"noopener nofollow\">wired.com<\/a><\/li>\n<li><a href=\"https:\/\/blog.cloudlinux.com\/php-cve-2026-109618-and-cve-2026-109619\" target=\"_blank\" rel=\"noopener nofollow\">blog.cloudlinux.com<\/a><\/li>\n<li><a href=\"https:\/\/sec.cloudapps.cisco.com\/security\/center\/content\/CiscoSecurityAdvisory\/cisco-sa-php-october26-Jj384Daq\" target=\"_blank\" rel=\"noopener nofollow\">sec.cloudapps.cisco.com<\/a><\/li>\n<li><a href=\"https:\/\/ubuntu.com\/blog\/php2shell-vulnerability-fixes-available\" target=\"_blank\" rel=\"noopener nofollow\">ubuntu.com<\/a><\/li>\n<li><a href=\"https:\/\/access.redhat.com\/security\/vulnerabilities\/RHSB-2026-013\" target=\"_blank\" rel=\"noopener nofollow\">access.redhat.com<\/a><\/li>\n<li><a href=\"https:\/\/www.php.net\/archive\/2026.php#2026-10-21-5\" target=\"_blank\" rel=\"noopener nofollow\">php.net<\/a><\/li>\n<\/ul>\n<\/section>\n<p><script type=\"application\/ld+json\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What should an organization do if it cannot update PHP immediately?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"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.\"}}]}]}<\/script><\/p>\n","protected":false},"excerpt":{"rendered":"<p>PHP has fixed two critical unauthenticated remote code execution flaws. Update web-facing PHP installations to the patched release for the installed branch.<\/p>\n","protected":false},"author":3,"featured_media":831,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-817","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/posts\/817","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/comments?post=817"}],"version-history":[{"count":5,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/posts\/817\/revisions"}],"predecessor-version":[{"id":849,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/posts\/817\/revisions\/849"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/media\/831"}],"wp:attachment":[{"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/media?parent=817"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/categories?post=817"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/managedt.com\/blog\/wp-json\/wp\/v2\/tags?post=817"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}